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Abstract 


The  mechanism  used  to  define  the  programming  language  PL/I  In  the 
recently  adopted  American  National  Standard  Is  presented.  This 
method  provides  a rigorous  though  seml-formal  specification  of  the 
language.  It  uses  the  model  of  translation  of  programs  Into  an 
abstract  form  to  define  the  context-free  and  context-sensitive 
syntax.  The  semantics  are  defined  by  the  Interpretation  of  the 
abstract  form  of  the  program  on  a hypothetical  machine.  The  method 
and  metalanguage  are  presented  along  with  several  small  examples  to 
Illustrate  the  definition  technique's  features.  The  complete 
definition  process  Is  shown  by  the  definition  of  a small  example 
language. 
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1.  INTRODUCTION  i 

1 

1.1  Prelude  i 

i 

It  is  all  very  well  for  Humpty  Durapty  to  say  "When  I use  a word. 

It  means  just  what  I choose  it  to  mean"  but  unless  the  audience  has  access 
to  his  dictionary,  understanding  is  very  difficult.  We  rely  heavily  on  the 
meaning  of  words  being  constant.  For  example,  when  we  buy  a bottle  of 
aspirins,  we  count  on  the  effect  of  the  tablets  being  essentially  the  same, 
no  matter  who  made  them,  advertisement  claims  notwithstanding. 

In  the  United  States,  the  U.  S.  Pharmacopia  assures  the  user  that 
the  drugs  it  lists  are  of  standard  composition.  Although  this  is  defined 

I 

primarily  for  the  pharmacist  and  is  written  in  a precise  technical  language, 
it  is  consulted  by  many  sophisticated  users  who  understand  its  terminology. 

The  standards  for  programming  languages  form  an  analogous  set  of 
definitions.  Their  existence  assures  the  user  that  a program  written  in  a 
standard  language  can  be  moved  from  one  Implementation  to  another.  However, 
the  definitions  are  directed  principally  at  the  implementor  and  not  the  user. 

Sophisticated  users  and  text-book  authors,  for  example,  will  also  want  to  read  i 

the  formal  definition  of  the  language  to  get  the  final  word  on  the  minutiae  ! 

of  the  language.  The  definition  is  not  a tutorial  document  but  must  provide  a 

I 

complete  and  unambiguous  specification  of  the  language  and  this  requires  a 

considerable  amount  of  formalism.  In  general,  this  formalism  has  been  absent  | 

in  the  past,  resulting  in  disparities  between  different  implementations  of  the  | 

i 

"same"  standard  language.  I 


L 


2. 

Recently,  a definition  of  the  programming  language  PL/I  prepared 

by  a Joint  Project  sponsored  by  the  European  Computer  Manufacturers' 

Association  (ECMA)  and  the  American  National  Standards  Institute  (ANSI)  has 

been  adopted  as  a standard  by  ANSI.  This  language  is  defined  in  "BASIS/1" 

I [E2]  using  a semi-formal  definition  method.  Although  languages  such  as 

BASIC  [L3] , ALGOL  68  [W4] , and  indeed  PL/I  itself  [A2,  A3,  L4 , L5]  have  been 

defined  formally,  this  is  the  first  time  in  a standard  that  both  the  syntax 

( and  semantics  of  a programming  language  have  been  defined  with  such  a 

( 

I 

degree  of  rigor. 

The  purpose  of  this  paper  is  to  present  an  Introduction  to  the 
definition  method  of  BASIS/1  h”  using  it  to  define  a small  artificial 
language,  SAL,  chosen  to  illustrate  the  salient  features  of  the  technique. 

The  small  size  of  SAL,  helped  by  many  examples,  permits  an  overall  view 
of  the  method  unimpeded  by  a mass  of  detail.  As  a further  simplification, 
we  have  only  described  those  parts  of  the  BASIS/1  formalism  required  for 
the  specification  of  SAL.  However,  we  indicate  where  metalinguistic  extensions 
are  needed  in  defining  a language  like  PL/I.  The  merits  and  demerits  of 
the  formalism  are  not  discussed. 

The  paper  Is  organized  as  follows:  section  1 is  an  overview  and 
discusses  the  PL/I  standardization  project  in  general,  sections  2 through 
4 define  the  metalanguage  of  BASIS/1,  sections  5 and  6 provide  a transition 
point  with  an  Informal  discussion  of  SAL,  and  sections  7 through  13  give  a 


formal  definition  of  SAL  using  the  metalanguage. 
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1.2  A Short  History  of  BASIS/1 

In  1969  the  Joint  Project  for  PL/I  standardization  was  launched  by 
ECMA  and  ANSI.  The  standard  was  developed  through  a process  of  successive 
refinements  of  the  working  document,  BASIS/1,  with  new  versions  published 
about  every  six  months.  As  a starting  point,  IBM  gave  the  project  their 
1969  March  PL/l  Language  Specifications  modified  to  exclude  some  Items 
thought  to  be  unsuitable  for  standardization.  These  PL/I  specifications 
were  written  in  English  and  the  Project  soon  realized  that  a more  formal 
style  would  be  necessary  to  obtain  the  required  precision  in  the  definition 

[B6].  I 

i 

The  IBM  Vienna  Research  Laboratories  had  by  that  time  published  a I 

I 

completely  formal  definition  of  a version  of  PL/I  [A2,  A3,,  L4,  L5]  in  i 

I 

what  is  now  known  as  the  Vienna  Definition  Language  [L3,  W3] . This  1 

definition  was  based  on  the  notion  that  Interpretive  execution  of  a ; 

program  on  an  abstract  machine  constitutes  a semantic  description  of  the  ' 

program.  Originated  by  McCarthy  [Ml,  M2],  Landin  [LI,  L2],  and  Elgot  [El], 

this  concept  was  first  followed  up  by  IBM  Vienna.  In  the  early  stages 

there  was  also  a parallel  effort  at  the  IBM  Hursley  Laboratories  in  England 

by  Beech  et.  al.  [A4,  B2,  B3,  B4],  who  favored  a semi-formal  definition 

of  PL/I  using  a machine-state  that  more  closely  resembled  actual 

implementations. 

Despte  the  perceived  need  for  a rigorous  definition,  the  Project 
felt  that  the  strict  formalism  of  the  Vienna  method  would  hinder  the 
acceptance  of  the  future  standard.  It  was  therefore  decided  to  base  the 
definition  on  the  Hursley  approach  and  retain  the  English  language  flavor. 

The  language  they  developed  to  define  I’L/I,  the  BASIS/1  metalanguage,  was 
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a seml-formal  programming  language  with  defined  phrases  that  express  the 
operations  used  in  the  definition  allied  to  a completely  formal  specification 
of  the  metalanguage's  operands.  Although  adopted  by  the  whole  project, 
the  bulk  of  the  work  was  carried  out  by  a relatively  mall  subcommittee  [B7]. 

In  accordance  with  ANSI  standardization  procedures,  beginning  on  March 
28,  1976,  BASIS/1  was  made  available  to  the  world-wide  computer  community 
for  public  comment.  The  result  was  twofold:  first,  several  small  technical 
errors  were  detected  and  second,  modifications  to  the  proposed  PL/I  were 
incorporated.  For  example,  the  standardization  committee  had  decided  to 
exclude  the  % INCLUDE  feature  from  standard  PL/ I on  the  grounds  that  its 
Inclusion  would  make  unfair  requirements  on  an  implementor's  operating 
system.  Public  outcry  from  structured  programming  enthusiasts,  however, 
led  to  the  incorporation  of  the  % INCLUDE  statement  into  standard  PL/I. 

BASIS/1  was  accepted  by  the  ANSI  subcommittee  on  standardizing  PL/I 
and  on  August  9,  1976,  ANSI  made  this  decision  official.  This  has  the 
following  Implication:  if  any  U.S.  government  agency  wishes  to  establish 
a standard  regarding  PL/I,  the  BASIS/1  standard  must  be  used.  For  example, 
if  the  U.S.  Army  wishes  to  buy  only  computers  with  standard  PL/I  compilers, 
then  those  compilers  must  conform  with  BASIS/1  [Sl]. 

The  current  activity  of  the  standardization  committee  is  to  develope 
subsets  of  PL/I  that  are  suitable  for  standardization.  This  task  had  been 
started  during  the  preparation  of  the  full  standard  but  was  postponed  for 
lack  of  effort.  Standard  subsets  were  also  requested  during  the  public 


comment  period.  A standard  realtime  programming  sublanguage  is  being 
developed  and  other  types  of  sublanguages  are  under  consideration. 
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i 
( 
i. 

* 1.3  PrerequisitES 

Tb  understand  BASIS/1  requires  some  acjquaintanoe  with  the  general  notion  of 
formal  syntax  aind  operational  semantics  as  well  as  a familiarity  with  some 
existing  version  of  PL/I.  Here,  we  assvme  some  tecJinical  background  in  formal 
syntax  and  semantics  althou^  a kncwledge  of  PL/I  is  not  essential.  The  reader 
is  referred  to  [b5]  for  a general  survey  of  the  structure  of  PI/I,  to  [Al]  for 
an  introduction  to  formal  syntax,  and  to  [1^2]  for  operational  semantics. 

2.  tto:  DPTINITION  method 

In  1962  Gcuwick[ci]  proposed  that  the  best  way  to  provide  a ccnpl ete 
definition  of  a programninq  language  was  a particular  iitp lamentation  on  a 
specific  machine.  This  method  of  definition  is  obviously  unsatisfactory  for 
a machine  independent  language,  nevertheless,  it  is  frequently  used  in  practice. 

It  is  not  unknown  for  an  iirplamentor  to  "correct"  a discrepancy  between  a 
compiler  and  its  manual  hy  changing  the  manual ! 

The  definition  method  of  BASIS/1  escapes  from  the  inevitable  interaction 
with  host  hardware  and  operating  system  by  making  use  of  a hypothetical 
machine  devoid  of  any  connection  with  specific  real  hardware.  The  definition 
is  thus  operational  in  nature,  l.e.  the  meaning  of  a construct  of  the  language 
is  specified  by  the  changes  its  execution  causes  in  the  state  of  the  machine. 
These  changes  are  described  algorithmically  in  the  definition,  not  because 
the  algorithm  must  be  followed  precisely  by  an  implementation  but  because 
it  is  a systematic  way  of  achieving  a complete  definition  of  a complex 
language,  thus  able  to  answer  unforseen  questions.  Implementations  are 
free  to  use  other  algorithms  and  to  take  advantage  of  particular  hardware 
features  to  provide  the  syntax  and  semantics  specified  by  the  definition. 


r 
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Using  the  operational  technigvie,  BASIS/1  hae  specified  every  detail  of  PL/I 
in  one  of  three  ways; 

- The  exact  specification  is  supplied  in  BASIS/1. 

- The  detail  is  specified  as  "iupl ementation  defined"  in  BASIS/1. 

For  exanple,  the  maxiimm  value  for  numbers  is  left  for  the 
in^lementor  to  define. 

- The  detail  is  specified  explicitly  as  being  "undefined".  For 
example,  the  sequence  in  vhich  subscripts  are  evaluated  is  undefined. 
This  mrians  that  the  inplementor  is  free  to  choose  the  sequence  but 
does  rot  need  to  specify  it  to  the  user. 

The  essential  point  is  that  there  aure  no  gaps  in  the  definition  vhere  nothing 
is  specified  at  all. 

BASIS/1  describes  what  an  implementation  must  do  to  conform  with  the 
standard.  As  Indicated  above,  an  implementation  is  given  great  flexibility 

and  may  also  choose  to  extend  the  language.  The  basic  measure  of  conformity 

/ 

is  that  the  implementation  must  provide  all  tlic  linguistic  features  defined 
in  BASlS/1  and  that  J nip Icmenta Lion  defined  extensions  must  not  effect  programs 
not  using  such  extensions.  Note  Lhat  conformity  is  not  that  a given  program 
with  given  Input  data  must  produce  tfu*  same  oiil  put  data  on  all  implementations. 

2.1  The  Abstract  Machine 

Although  abstract,  the  hypothetical  machine  used  in  the  definition  has 
a considerable  resemblance  to  the  architecture  of  the  real  machine.  The 


1 


abstract  machine  is  shown  schematically  in  Figure  1. 


The  machine  has  a set  of  operations  defined  by  algorithms  that  make 
use  of  a small  set  of  standard  basic  instructions.  Thus  the  algorithms 
are  analogous  to  the  microcode  of  a real  computer. 

The  machine  also  has  a memory  whose  contents  can  be  changed  by  the 
machine  operations.  In  this  memory  are  stored  the  information  used  to 


control  the  execution  of  machine  operations,  a representation  of  the  program 
being  defined,  and  the  values  of  the  program's  variables  and  datasets  during 
its  interpretation.  The  abstract  machine's  memory  is  thus  the  equivalent 
of  both  a real  computer's  main  store  and  its  microcode  working  store, 
together  with  on-line  auxiliary  storage.  At  any  point  in  the  definition 
process,  all  the  information  in  the  memory  is  represented  by  a single  tree 
that  defines  the  "machine-state." 

2.2  The  Definition  Process 

PL/I  is  defined  by  specifying  the  set  of  legal  states  of  the  abstract 
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machine  and  by  defining  algorithms  for  the  machine  operations.  These 
operations  are  linked  together  Into  a single  algorithm  whose  behavior 
specifies  the  meaning  of  any  PL/I  construct.  For  clarity  of  presentation, 
the  algorithm  Is  viewed  as  two  separate  processes:  a translator  which 
consists  of  parser  and  constructor  phases,  and  an  Interpreter.  Figure  2 
shows  a schematic  representation  of  the  definition  algorithm. 


CHAMCTBR 

LIST 


.OUTPUT 

PILES 


Figure  2.  The  Definition  Process 


The  first  step  is  to  read  In  a list  of  characters  representing  the 
program  to  be  defined.  An  attempt  is  made  to  parse  this  character-list 
according  to  the  syntax  of  the  written  language.  We  use  "attempt"  here 
because,  throughout  the  definition,  checks  are  made  that  the  program 
being  defined  is  valid  by  the  rules  of  the  language.  If  the  program 
fails  any  one  of  these  tests  it  is  rejected  and  the  definition  process 
stops  at  that  point,  leaving  the  meaning  of  the  Illegal  program  undefined. 
Only  a valid  program  has  a defined  meaning. 

Parsing  the  program  transforms  It  character-list  representation  into 
a tree  structure,  the  "concrete  program,"  stored  in  memory.  The  next  step 
is  to  construct  from  this  concrete  program  an  internal  form  suitable  for 
interpretation,  the  "abstract  program."  The  translator's  parsing  and 


construction  phases  have  many  analogies  with  the  phases  of  a compiler 
that  build  the  Internal  form  of  a program  prior  to  the  code  generation 
stage.  The  result  is  an  abstract  form  of  the  original  program  where  all 
the  syntactic  devices  required  in  the  written  form  of  the  program  have 
been  deleted  and  only  those  parts  that  are  concerned  with  its  meaning 
remain.  During  this  translation  phase,  further  validity  checks  are 
made  on  the  program.  For  example,  there  is  a check  that  no  Illegal 
combinations  of  data-types  are  present  in  expressions. 

The  final  step  in  the  definition  process  is  the  interpretation  of 
the  abstract  program.  During  this  phase,  the  abstract  machine  behaves 
very  much  like  a real  computer  executing  a program.  For  instance,  part 
of  the  machine-stare  contains  the  values  of  the  program's  variables,  while 
another  part  keeps  tract  of  the  current  statement  being  executed.  In 
addition,  the  abstract  machine  reads  and  writes  datasets.  The  meaning  of 
the  program  is  defined  by  the  sequence  of  machine  states  generated  as 
the  program  is  interpreted. 

The  existence  and  relationships  of  the  machine-state,  the  three 
forms  of  the  program,  and  the  datasets,  as  used  in  the  definition  process, 
are  Illustrated  in  Figure  3,  an  expansion  of  Figure  2. 
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of  node  • Nodes  Innnedlate  subnodes  of  and  are 

Immediately  contained  by  node  ^ node's  Immediate  subnodes  are 

ordered  from  lef t-to-rlght  and  the  meaning  of  the  terms  "first",  "last", 
"leftmost",  "rightmost",  and  "follows"  are  applied  intuitively.  Some  nodes, 
for  example,  have  any  subnodes.  These  are  the 

terminal  nodes  of  the  tree. 


Node  (T)  is  the  root  node  of  the  tree.  Each  of  the  other  nodes  are  subtree 
nodes  forming  four  iirmediate  siiJtrees.  Nodes  (^,  (^,  (^t  and  are  the 
root  nodes  of  these  subtrees  and  tliemselves  ccntain  subtrees,  and  so  on.  Sate 
subtrees  are  degenerate  in  that  they  consist  of  only  one  node,  the  root  node. 

A reference  to  the  root  node  of  a tree  is  a reference  bo  the  vdiole  tree  unless 
otherwise  stated. 

Eich  node  hcis  a type  associated  with  it.  In  Figure  3,  for  example,  these 
are  "A",  "B",  . . . , "J".  In  one  tree  there  may  be  several  distinct  nodes  of 
the  same  type,  for  exanple  nodes  and  are  both  of  type  "D". 

Although  not  used  in  defining  SAL,  BASIS/1  uses  additional  tree 
terminology  to  aid  in  defining  PL/l's  procedure  calls,  argument  lists, 
and  data  structures. 

3.2.  The  ftochine  State 

The  machine-state  is  a tree  structure  that  completely  represents  the 
state  of  the  abstract  machine  at  all  stages  in  the  definition  process.  There 
arh,  of  course,  rules  by  which  the  tree  is  constructed  just  as  there  aue  rules 
by  which  valid  sentences  of  a lauiguage  can  be  constructed.  These  are  the 
rules  which  comprise  the  syntax  of  the  language.  Similarly,  we  can  refer  to 
the  rules  for  constructing  the  machine-state  tree  as  the  machine-state  syntax. 
These  rules  specify  the  types  of  nodes  that  may  be  connected  together  in 
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Although  there  is  just  one  tree  throughout  the  definition,  there  are 
two  distinguishable  subtrees  of  the  machine-state  that  play  major  roles. 
Hence,  for  convenience  only,  we  Isolate  these  subtrees  and  describe  them 
by  three  quasi-separate  syntaxes. 

During  the  translation  from  the  character-list  form  of  the  program 
to  its  abstract  form,  the  concrete  program  is  a subtree  of  the  machine- 
state.  The  syntax  of  the  concrete  program  is  defined  by  a separate  set 
of  rules  comprising  the  concrete  syntax.  The  terminal  nodes  of  the  concrete 
program  are  the  characters  of  the  written  form  of  the  program.  Thus  the 
' concrete-S3mtax  defines  the  character-list  representation  of  the  set  of 

syntactically  valid  programs. 

The  abstract  program  is  another  separate  subtree  of  the  machine-state. 
It  is  the  end  product  of  the  translator  and  it  is  constructed  in  accord.ance 
with  the  abs tract -syntax . The  terminal  nodes  of  the  abstract  program  are 
not  characters  of  the  language  being  defined;  rather,  they  are  abstract 
entities  used  for  program  interpretation. 

3.3  The  Metabrackets 

iTte  three  syntaxes  are  defined  in  Bac3cus-Naur  Form,  BNF  [Bl],  vdth  a 
fa/  extensions  as  described  in  Section  3.4.  Tb  help  distinguish  the  type 


names  used  in  the  three  syntaxes,  characteristic  metabrackets  aure  used  as 
part  of  the  name: 
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The  concrete  syntax  has  the  symbols  and  keywords  of  the  programming 
language  as  Its  terminal  symbols.  The  other  two  syntaxes  denote 
terminal  symbols  by  underlining  the  type  name.  For  example,  <flxed>  and 
! ^undeflned»  are  respective  terminal  symbols  of  the  abstract  and  machine- 

I 

} State  syntaxes. 

I 

! 

i 

' 3,4.  The  Definition  of  Trees 

I The  rules  of  syntax  are  expressed  as  production  rules  in  slightly 

I extended  ENF.  For  exeirple,  consider  the  BNF  production: 

i ^expressions  : : = iexpression-twD> 

J 

I i:expression>  + texpression-two> 

? 

This  production  specifies  that  ein  ^expressions  node  may  either  have  a 
I single  subnode,  an  IfexpressionrtwoS,  or  it  may  have  three  subnodes,  an 

I flexpressionS  fol  lowed  hy  a "+"  fol  lowed  by  an  fexpressicn-twoS. 

1 

The  syntx)ls  cind  "I"  are  metasyntxils;  they  cU?e  not  peurt  of  the 

t 

language  being  defined,  but  part  of  the  definition  mechanism.  In  addition 

I 

: to  these  metasyntols  of  BNF,  the  syntax  rules  in  BASIS/1  also  use 

i 

and"}".  These  extra  roetasymbols  are  used  as  follows: 

!•  "I"  and  enclose  an  optional  syntactis  expression.  The  production 
rule  for  ^expressions  given  above  can  be  written  equivalently  as  rule 
HL16  in  the  concrete  syntax  of  SAL: 

HL16  jrcxpression^  ::«»  [^expression^f  +]  ^expression-two^ 

2-  "I"  and  "}"  enclose  a syntactic  expression,  generally  a set  of 
options  from  which  one  must  be  chosen.  For  example,  also  from  the 
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ooncarets  syntax  of  SAL: 

HL15  |logical-expression>  identifiers 

I ixpressionS  I ¥)  ^expressions 
Ihis  production  states  that  a logical— expressions  either  has  a single 
identifiers  iramediate  oorponent  or  it  has  three  iimediate  oonpcnents, 
two  ^expressions  ncxies  separated  by  either  an  "="  or  a "f"  character. 
Although  not  needed  to  define  SAL,  BASIS/1  uses  an  additional  "permutation" 
metasymbol  to  reduce  the  number  of  BNF  productions  needed  to  express  the 
fact  that  PL/I's  myriad  of  data  attributes  may  be  listed  In  any  order  in 
data  declaration  statements. 


If  we  add  the  foil  owing  productions  to  HL15  and  HL16: 

HL17  Cexpression-twoS  [<:expression-twoS  *]  <:expressionroneS 

HL18  ^expression-oneS  ::=  fprunitive-expressionS 

I - <:expression-oneS 

I ( ^expressions  ) 

HL19  tprimitive-expressionS  <:identifierS 

I f constants 


we  can  draw  an  exanple  fran  the  set  of  trees  of  vrtiich  ^^expressions  is  the 
root  node. 


^constants 


Ber^viPf>  this  tree  does  not  have  all  its  terminal  nodes,  it  is  called  a 


An  alternative  to  this  grapiiic  representation  of  trees  is 
their  dsscxiption  by  "enviteration" . The  enunerated  tree  form  of  the  above 


partial  tree  is: 


^expressions: 

^expressions ; 

texpression-twoS : 
fexpressior^-oneS : 

liprimi  tive-expressionS : 
^^identifiers;;;; 

+ 

te>qjression-t«DS : 
<e;q3ression-oneS : 

ilprimitive-expressionS ; 
toons tantS. 


The  rules  for  describing  trees  by  enumeration  are: 

1.  the  type  of  root  node  is  listed.  Optionally,  this  is  followed 
by  a colon  and  a listing  of 

2.  the  immediate  components  of  the  root  node.  Each  of  these 
components  may  Itself  be  an  enumerated  tree. 


An  enumerated  tree  is  terminated  by 


3.  a semicolon.  A string  of  semicolons  at  the  end  of  an  enumerated 
tree  may  be  replaced  by  a period. 
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If  a particular  node  of  an  enunerated  tree  is  to  be  referenced  specifically, 

the  type  name  of  the  node  ccin  be  followed  by  a ocitina  and  a local  name  for 

the  no<te.  Thus,  in  the  partial  tree: 

<expression>: 

<:expression> : 

texpres  sion-  two  y : 
fexpression-one>; ; 

+ 

fexpression-two^,  rx: 

<lex|iress  ion-one> . 

the  name  rx  can  be  used  to  refer  to  the  second  ^expressior^ti«)D^  node. 


For  clarity,  enumerated  trees  are  generally  shown  In  an  Indented 
form.  However,  the  notation  does  not  depend  on  this  for  unambiguous 
representations  of  a tree. 


Frequent  use  is  made  of  sequences  of  one  or  more  nodes  of  the  same  type. 
Fbr  exemple,  in  the  abstract  program  the  statements  of  the  ooncrete  program 
are  represented  by  a sequence  of  <executabl&*unit>  siiitrees.  These  are 
collected  together  as  imnediate  oonponents  of  an  <executabl e-uni t-list>  node. 
This  rctatir-.i  is  usetl  wherever  lists  an?  required  in  the  -^nachine-state^ . 
Similarly,  in  the  ooncrete  (program,  there  is  frequent  use  of  nodes  of  the 
sane  tyix;  .sef^arateil  tiy  oonma  ncxles.  'TlMJse  are  collected  together  as  imnediate 
subncxJRJi  of  a -ccjnnaUst  rKxle.  The  form  of  the  enunerated  tree  for  a 


icteclaration-cdnnalistV  is: 

tdeclaraticn-aonmal  ist>: 
{:declaration>. 


tdec  1 ara  tion-oemna  1 is  t> : 
fdecl  aration^ 

i,> 

l:declaration>. 


fdecl aration-aormal ist>: 
<decl  curaticn> 

i,> 

fdecl arationV 
<:declaration>. 


and  so  on.  The  metabrackets  around  the  commas  are  used  to  avoid  conflict 
with  the  notation  of  the  enumerated  tree. 
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3.5.  Uhiqv>e-nanes  euid  Designators 

Each  node  of  the  -^Tachine-state^  has  a unique-name  implicitly  associated 
with  it.  During  the  definition  process  each  node,  as  it  is  created,  is  given 
a unique-name  that  is  different  fran  the  unique-names  of  all  previously  created 
nodes,  whether  or  not  thtse  nodes  still  exist.  These  unique-names  can  be 
visualized  as  the  circled  reference  nimbers  on  the  nodes  in  Figure  4. 

Seme  nodes  are  of  type  -<designator».  A designator  node  contains  a copy 
of  the  unique-name  of  some  other  node  and  thus  points  to  that  node.  Althou^ 
designator  nodes  can  point  to  any  type  of  node,  generally,  for  clarity,  they 
point  to  one  type  of  node  only  and  have  a type  name  that  contains  "-designator" 
as  a suffix.  For  exanple,  a <declaration-designator>  is  a node  that  only 
points  to  <declaration>  nodes.  In  the  abstract  program  a <variabl e-ref erenoe> 
contains  a <declciration-designator>  that  points  to  the  <declaration>  for  the 
variable  being  referenced.  Figure  5 shews  the  way  that  this  takes  place  in  the 
<progran>. 


<pro«)ran»> 


I 

I 

Figure  > . A fragment  of  an  abstract  program  with  a designator 

Designators  and  trees  are  such  that  it  is  possible  to  reference  the  nodes 
tiiat  contain  a designated  node  as  well  as  the  carfonents  of  the  designated  node. 
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TVjo  trees  are  said  to  be  equal  if  they  differ  only  in  the  unique-nanes 
of  their  nodes.  A cx:py  of  a tree  is  constructed  ty  creating  a tree  equal 
to  the  given  tree  and  then  changing  any  designators  in  the  newly  created  tree 
that  point  to  nodes  in  the  given  tree  to  point  to  the  corresponding  nodes 
in  the  new  tree. 


4.  THE  ABSTllACT  MACHINE  OPERATIONS 

Ihe  operations  of  the  abstract  machine  are  specified  by  algorithms  expressed 
in  English  prose.  Although  this  makes  the  definition  somewhat  less  formal, 
each  algorithm  is  presented  in  a standard  format  and  is  written  using  precisely 
defined  keywords  and  phrases,  in  effect  a kind  of  prograiming  language.  A 
nachine  operation  algorithm  has  many  characteristics  of  a program;  it  has 

local  variables  that  designate  nodes  on  the  ^machine-states,  it  can 
create  temporary  trees,  and  there  are  basic  instructions  for  manipulating 
trees  and  doing  arithmetic.  Operations  may  Invoke  one  another,  possibly 
recursively,  passing  arguments  and  returning  values.  Internally,  the 
control  schemata  are  the  usual  si-quoiit  la  I , cond  i t tonal , and  iterative 
forms . 

In  defining  SAL  we  will  use  all  of  the  abstract  machine  Instructions 
that  are  used  in  BASIS/1  to  define  PL/I. 


I 
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The  Execution  of  Operations 


At  any  time  during  the  abstract  machine's  execution,  there  is  one 
"active"  operation,  i.e.,  the  one  that  the  abstract  machine  is  currently 
executing.  The  ■^operation*'  tree  describing  it  is  the  rightmost  element 
of  an  ■«:operation-llst>  in  the  -^machlne-statei* , as  described  in  the  next 
paragraph.  Each  ■‘operat lon»-  has  a subtree  containing  a list  of  designators 
pointing  to  its  parameters,  local  variables  with  their  current  values, 
locally  constructed  trees,  and  an  indication  of  where  in  its  algorithm  it 
is  currently  executing  (i.e.,  a location  counter).  The  invocation  of  an 
operation  causes  its  ■<operation>  tree  to  be  added  to  the  right-hand  end  of 
the  •<operation-llst»  and  it  thus  becomes  the  active  operation.  When  the 
operation  terminates,  it  and  any  temporary  trees  it  has  created  are 
deleted  from  the  list  and  the  operation  that  invoked  it  once  again 
becomes  the  active  operation,  resuming  at  the  point  of  suspension.  In 
BASIS/1,  the  exact  structure  of  an  -<operatlon>  is  left  unformalized  and 
unspecified  since  it  is  assumed  that  the  workings  of  the  operation  can 
be  understood  without  lower  level  of  detail. 


Tlie  -^machine-state^  at  the  start  of  the  definition  process  has  a -^control- 
i state*  ocHTpcnent  with  an  -toperation-l ist*  containing  a single  operation 

named  "define-progrcn".  This  operation  invokes  other  operations  that  build 
' the  ooncrete  program,  translate  it  into  the  abstract  program  and  then  start 

its  interpretation.  At  this  point,  the  situation  is  similar  to  that  of  an 
I operating  system  that  has  loaded  a prctolem  program  and  is  starting  its 

[ executJTi.  Oontrol  is  passed  to  the  problan  program,  often  with  a change  of 

I 

1 

I hardware  locaticn-oounter.  In  the  aibstract  machine  a -^program-oontrol  * 

[ oonponent  of  tlic  -^raaclune-statc*  is  created  containing  a second  ^operation-list* 


while  it  exists,  its  rightmost  element  is  the  active  operation. 


The 
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operation  at  the  right-hand  end  of  the  -^operation-list^  in  the  ■<aontro1 -statae^ 
is  put  into  a state  of  suspended  animation  until  the  ^prograrj-oontrol > amd 


its  -^operaticn-l  ist>  ^ms  deleted  from  the  •<machine-state>.  That  happens 
vhen  the  interpretation  of  the  abstract  progren  terminates. 


4.2.  Operation  Ftarmat 

The  following  example  is  an  operation  of  the  abstract  machine  which 
defines  SAL.  It  is  not  expected  that  the  reader  will  fully  understand 
the  operation  at  this  point.  It  Is  presented  here  to  illustrate  the 
structural  features  common  to  all  operations. 


Operation:  create-assignment-staten>ent(cas) 

where:  cas  is  an  l:assignTient-stabaTient> 
result:  an  <assigiTnenb-statanent> 

Step  1.  Let  id  and  cx  be  respectively  the  immediately  contained  ^identifiers 
and  <expresijcxi>  of  cas. 

Step  2.  Perform  find-abstract-declaration  (id)  to  c±)tain  a <Qecl aration- 
designator>,  dd. 

Step  3.  Perform  create-expression(cx)  to  obtain  am  <expression>,  e«. 

Step  4. 

Case  4.1.  ax  iirmdiately  contains  a <variable-referenae>,  vr. 

The  <attribute>  contained  by  ttie  <declcLration>  designated  by 
dd  must  cxpjal  the  <attril7ute>  contained  by  the  <declauration> 
dcsiqnaLc(i  by  tfic  <doc1aration-ciesignator>  of  vr. 

Case  4.2.  ax  imncxlialjely  contaia-:  a <constant>,  c. 

It  c contains  an  •<inte<}er-val  ue>  then  the  <declaration> 
designated  by  dd  must  contain  <fixed>,  otherwise  it  must 
contain  <bit>. 

Case  4.3.  (Otherwise). 

The  <declaration>  designated  by  dd  must  contain  <fixed>. 

Step  5.  Return  an 

<assigrrKnt-statemont> : 

<variablo-refcrencx;> : 

dd; 

ax. 

The  written  description  of  the  operation  consists  of  a heading  emd  a 
body.  The  heakling  always  contains  the  word  "Operation"  and  the  uraierlined 
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operaticn  naro.  The  rerainder  of  the  heading  depends  on  the  details  of  the 
operation,  vhether  it  has  parcfneters,  and  vhether  it  returns  a value.  The 
operation  create-assigment-statement  has  a single  parateter  with  the  local 
name  "ceis".  A pcirameter  is  a designator  pointing  at  a node  in  the  -^nachine- 
state>,  possibly  in  the  caller's  local  storage.  Parameters  are  thus 
passed  by  reference  and  it  is  possible  to  change  the  value  of  the  tree 
designated  by  the  parameter. 

The  types  of  the  nodes  designated  Ijy  the  parameters  are  specified  in  the 
where-clause.  In  ocme  operations  there  may  be  several  alternative  types  for  a 
parameter,  the  particular  one  actually  designated  varying  from  invocation  to 
invocation.  In  our  exanple,  the  parameter  cas  designates  an  <assigiinent- 
stateiiient>  node  and  thus,  the  whole  tree  of  which  it  is  the  root  node.  An 
operation  may  return  a ccrnplete  tree,  in  which  case  the  type  of  its  root  node 
will  be  specified  in  tlie  result-clause  of  the  heading.  The  create-assigiment- 
stateiient  operation  returns  a ocmplete  tree  with  an  <assignTient-staterient> 
root  node. 

The  body  of  an  oyxiration  oonsisU;  of  oitlier  a sequence  of  Stejvs  or  a set 
of  mutually  exclusive  Cases,  nimljered  sev jntmtial  ly.  Kach  Stop  or  Case  can 
itself  contain  a nested  soquenoe  of  Stcyis  or  a sot  of  Cases.  If  so,  the 
nixrijorinq  in  the  i'tii  Step  or  Case  will  ho  sequential  frem  i.l.  This  nested 
structure  continues  to  ai±)itrary  depth.  The  Steps  of  an  operation  are  executed 
secyuential  ly  except  when  modified  by  a control  instruction.  Each  Ccise  is 
precevled  by  a predicate  whose  truth  value  determines  \Nhetlier  tlve  body  of  the 
Case  is  to  bo  executed.  There  must  always  be  one  and  only  one  Case  whose 
predicate  is  true  when  any  set  of  Cases  is  executed.  Ftor  brevity,  the  predicate 
of  the  last  Case  iiviy  be  " (t)thcrwise) " which  is  true  if  and  only  if  all  the 
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Other  Cases  are  false.  This  abbreviation  is  only  used  vrtiere  it  saves  vnriting 
out  a ler^thy  negation  of  all  the  previous  predicates. 

4.3.  Vari^les 

In  the  body  of  the  operation,  local  variables  cure  used  to  designate  parts 
of  the  ^machine-state->,  locally  constructed  trees,  and  parameters. 

They  may  also  be  used  to  contain  integer  values.  These  local  variables 
are  given  names  consisting  of  a few  alphanumeric  characters,  usually  of 
mnemonic  significance.  By  convention,  these  names  are  distinct  from 
English  words  to  avoid  confusion  with  the  text.  Local  variables  may 
be  subscripted.  For  example,  nt[i]  is  an  element  of  a vector  of  local 
variables  nt,  the  value  of  the  variable  i determining  a particular 
element . 

Both  local  variables  and  locally  constructed  trees  exist  only  for 
as  long  as  the  operation  is  on  an  eoperation-1 ist>-.  As  soon  as  the 
entry  is  deleted  from  the  list,  the  local  variables  and  trees  cease  to 
exist.  However,  a local  tree  may  be  returned  as  a value  of  an  operation, 
in  which  case,  it  is  copied  to  form  a local  to  the  caller. 

4.4.  Tree  manipulation  instructions 

The  let  instruction  makes  a local  vcuriable  designate  an  existing  tree  or 

a newly  created  tree.  Ft>r  exavple,  in  the  operation  create-assignnent-statenient; 

Step  1.  Let  id  and  cx  be  respectively  the  innediately  contained 
^identifiers  and  Expressions  of  cas. 

Hie  Vcuriable  cas  is  a fiarameter  of  the  operation  and  designates  an  l^sigironb- 


1 

I 


statement^  node  in  tlio  concrete  nrogreim.  Tliis  node  is  defined  by  the  Cbncrete 
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Syntax  rule: 

lILll.  tessiqr#nent-stateJTient>  <:identifier>  = Cexpression> 

Ttiis  let  instruction  creates  two  local  vciricibles,  id  amd  cx,  which  respectively  < 

I 

designate  the  <identifier>  and  i:expression>  iitmediabc  oonponents  of  the  node  | 

designated  by  cas.  iVDth  these  trees  existed  before  the  let  instruction  was  j 

executed.  In  the  following  let  instruction:  i 

Let  dso  be  1 

•toutpu  t-datase  : i 

•<dataseb>:  ' 

•<alpha» 

■<cnega>. 

i 

a tree  is  constructed  and  the  local  variable  dso  is  made  to  designate  it. 

Another  way  to  oonstruct  a tree  is  by  copying  trees  designated  hy  local  variables. 

For  exanple: 

let  ids  be  ’ 

<input-dataset> : 
ds 

•<currcn  t-rosi  tion> : 

dg;  ; 

Here,  a tree  with  root  node  of  t^Tc  input-datasets  is  constructed  and 
one  of  its  utmediatc  oam:x)nents  is  a conv  of  tlie  trc?e  designated  by  the 
local  varicdile  ds.  Similarly,  the  new  constructed  tree  contains  a copy 
of  the  tree  designatc'd  by  the  a local  variable  da.  The  variable  ids 
designates  the  entire  ne^ly  ocaastructed  tree. 

There  is  an  Implicit  form  of  the  let  instruction  in  which  the  name 
of  a local  variable  is  listed  fol lowing  some  description  of  a root  node 
and  a comma.  For  example,  in  the  predicate  of  the  case: 

Case  1.1.2.  cx  Immediately  contains  a ^constant^,  cn.  jf  the 
predicate  is  true  then  the  local  variable  cn  is  made  to  designate  the 
^onstant:^  node.  This  form  of  the  let  instruction  can  also  be  used  In 

I 

I 

I 
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enumeratml  trees. 

The  let  iiistrxiction  is  also  used  to  introduoe  a vector  of  local  variables. 
For  example: 

Let  nt[i],  i = be  the  ordered  list  of  nodes  vMch  are  the 

inmediate  oorponents  of  the  <delimiter>  and  <:nDn-delijtiLter>  nodes  of  t. 

sets  a vector  of  n designators  nt.  References  to  elements  of  this  vector  will 
be  subscripted  witb  a local  variable  containing  an  integer  value. 

The  replace  instruction  is  used  to  substitute  a specific  tree  for  a 
tresc  designated  by  a local  variable.  For  exaimle: 

Replace  the  <basio-val designated  by  bvd  by  a copy  of  bv. 

Hic  replacement  takes  place  at  the  nale  ilesignated  Itv  tloe  local  variable 
and  the  unique  name  of  the  original  node  becomes  the  unique  name  of  the 
root  of  the  replacement. 

The  append  instruction  attaches  a tree  as  the  rightmost  elanent  of  a list. 

By  definition,  there  aire  no  apty  list  nodes  in  the  -^nachine-state^.  Tb  avoid 
special  cases,  the  append  instruction  will  construct  the  -list  node  if  it 
is  appending  an  element  to  a non-existant  list.  Fbr  exentple: 

Append  an 

<executabl e-uni t> : 
id 

axs; 

to  the  <executable-unit-I i st>  of  the  <program>. 

Here,  the  append  instruction  causes  a tree  consisting  of  an  <exBCutabl e-uni t> 
with  two  ijimediate  conpenents  to  be  built  euxi  then  added  as  the  rightmost 
cnTponent  of  the  <cxecutable-unit-list>  inmetliately  contained  by  the  aha  tract 
progran.  The  first  time  this  instruction  is  executed,  the  <exBcutabl  e-uni  tel  is  t> 
node  will  have  to  be  crcatetl  and  connected  to  the  <program>  node. 
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The  action  of  the  renaining  tree  manipulation  instructions,  unlike  those 
described  so  far,  depends  on  the  syntax  of  the  trees  being  manipulated. 

Hie  attach  instruction  constructs  a tree  by  joining  a specific  tree  bo  a 
designated  norle.  Ho  make  the  link,  the  instruction  may  create  the  miniimin 
nurher  of  intervening  nodes  required  by  tie  syntax  rules  for  the  tree. 

For  excmple,  the  tree  for  a <:declcu:ation>  is  defined  by  the  rules: 


HL5.  declaration^  ::=  <identifier>  [fattrihute^] 
HL6.  dttribute>  ::=  FIXED  | BIT 


Suppose  tile  local  variable  d designates  a f docl £uration>  that  does  not  contain 
an  dttribube^  emd  thus  can  be  represented  as: 


fdeclcurationk 


l:identifier> 

Then  the  result  of  executing  the  instruction 
Attach  FIXFD  to  d. 

is  to  make  the  tree  designated  bv  d look  liJ'.e: 


{:fleclarntion> 

I * 1 


^identifiers  dttributeS 


FIXED 


The  delete  instruction  causes  a designated  tree  to  be  deleted  fron  its 
containing  tree.  If  the  deleted  tree  was  a mandatory  cerponent  of  i'cs 
ijimdiatcly  containing  node,  then  this  node  is  also  deleted  amd  the  process  is 
repeatcfl  until  a legal  tree  is  obtained.  All  deleted  nodes  cure  discarded  and 
cease  to  exist.  For  example,  part  of  the  4nachine-state^  is  defined  by  the 


J 
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rules: 

M5.  •<interpretation-state»  ::=  [•<r)roqram-statx?>l  ^datasets^ 

M6.  •<prDgram-state»  ::=  ^proqrcwn-cxDntrol^  -^al located-storago^ 

Hxecution  of  the  instruction 

Delete  the  ^program-control^  from  the  -^TiaciTine-state^. 

raroves  the  ^progran-oontrol^.  But,  since  it  is  a rerjuired  oonponent  of  ^rograrf- 
state»,  the  -^program-state^  node  and  its  corgxjnents  are  also  deleted  fran  the 
•^chine-state».  'Ihe  -fprogram-state^  in  only  an  optional  node  of  the 
■<intcrpretation-state»  and  ttierefore  the  deletions  stop  at  this  point. 

4.5.  Control  Instructions 

The  execution  sequence  of  an  operation's  steps  follows  the  order 
in  which  they  are  written  unless  one  of  the  control  Instructions  is 
executed.  In  the  normal  sequential  flow  of  control,  once  the  last 
step  of  an  operation  has  been  executed  the  operation  is  terminated  and 
deleted  from  the  -^operation-list^ , thus  returning  control  to  the  operation 
that  Invoked  it. 
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The  return  instruction  not  only  returns  control  to  the  invoking  operation 
hut  also  passes  back  a valve.  If  the  returned  valve  is  a local  tree  belonging 
to  the  operation,  the  tree  is  copied  to  leocne  a local  tree  of  the  calling 
operation.  ’ example: 

Return 

< 1 og  ica  1 -expms  s ion  > : 

<Vcu:iaid  o-rcf  eronce> ; 
dd. 

sends  the  specified  tree  back  to  the  caller  where  it  will  be  designated  by 
a local  variable. 

Control  is  passed  to  another  operation  by  invoking  it  with  the  perform 

instruction.  For  exanple,  the  instruction: 

Perform  create-logical -expression (cl  e)  to  obtain  a <logical- 
expression>,  alx. 

causes  the  create-logical-expression  operation  to  be  invoked.  The  local 
variable  cle  strictly  designates  a tree  and  this  designator  is  passed  as 
an  argument.  An  ■♦operations  for  create-logical-expression  becomes  the 
active  operation.  During  this  activation,  the  designator  value  being 
passed  as  an  argument  is  given  a local  name  and  is  treated  like  a local 
variable.  The  "obtain"  part  of  the  perform  Instruction  is  optional. 

Where  applied,  it  describes  the  type  of  value  to  be  eturned  and  specifies 
a local  variable,  in  this  case  alx,  to  designate  tnis  returned  value. 

When  control  is  returned  to  the  calling  operation,  execution  resumes 
immediately  following  the  perform  instruction. 

In  some  circumstances,  usually  after  a program  execution  error,  it 
Is  an  Implementation  decision  wlietlier  an  operation  is  to  be  performed. 

In  these  cases,  the  phrase  "optionally  perform"  Is  used.  For  example, 

i 
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in  the  instruction 

"If  the  magnitude  of  ir  exceeds  an  implementation-defined  maximum, 
then  let  ir  be  an  -^integer-value*-  with  an  implementation-defined 
value  and  optionally  perform  abnormal-termination." 

if  the  computed  value  ir  has  a maximum  greater  than  the  implementation's 
maximum  allowable  value,  the  implementation  has  the  option  of  continuing 
o r terminating  the  program's  execution. 

TIk'  for  oach  instruction  srxicifics  that  a satucncjn  of  instructiors  is  to 

be  executiMl  once  witli  each  member  of  a sf^t  of  olnects.  Rjr  cxanple: 

For  each  <varia})le-rofcrcnce>,  vr,  of  the  <variab1e-reference-1 ist> 
of  St,  taken  in  left-to-riqht  onlcr,  perform  Steps  1.1  through  1.4, 

Here,  the  perform  instruction  is  used  to  cause  the  execution  of  a self-contained 

group  of  sv±)steps  similarly  to  the  way  that  it  is  used  to  cause  the  execution 

of  a oofTipletr-  <jperation.  Hie  Steos  1.1  tliroixfli  1.4  will  be  executed  once  for 

each  el<3Tvent  of  the  <variabl  e-rcference-1  ist>.  Each  time  they  are  executed,  the 

local  variable  vr  will  designate  the  <varialile-referenoe>  currently  being 

ofierated  on.  Unless  an  ordering  is  sfiocified,  as  it  is  in  this  example,  the 

onler  in  wliich  the  elements  of  tlie  list  are  chosen  for  processing  is  arbitrary. 

'The  if  instruction,  althox»jTi  strictly  s[x:akinq  not  a control  instruction 


sincxi  it  doe.s  not  cliarv^e  tTie  onler  oT  oxecuLion  of  Steps,  does  have  some  effect 
on  the  ext'cution  of  tin-  insLtUvnions  in  die  Step.  Hio  if  instruction 
SfKcifiis  tliat  in  tiie  case  tlial  tin  stated  condition  is  true,  the  instruction 
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list  that  follows  the  then  is  to  be  execLited.  For  example: 

If  the  ri<^tniost  imediate  ccmpf;nejit  of  ul  does  not  contain 
freturn-statanent^  then  aptjeiv.! 

<unit>: 

<execuL.(lj  1 ( “lu  i it  ^ : 

fcxccu  tab 1 e- s ing 1 e-s  tatanent> : 
tretum-statcsnent^: 

RETtIRN 


Optional  ly,  the  if  instruction  can  oontain  cin  otherwise  part,  in  which  case 

the  instrtctions  that  fol  low  it  are  executed  only  if  the  stated  condition  is 

false.  Thus,  for  example,  in  the  instruction: 

If  cd  contains  FIXED  then  attach  <fixed>  to  ad,  otherwise  attach 
<bit>  to  ad. 

if  the  condition  "t}>c  ncxle  designatixl  kjy  cJ  contains  FIXED"  is  true,  then 

the  node  <f ixed>  wil 1 be  attached  bo  the  nock;  designated  by  ad.  If  the  | 


condition  is  false,  <bit>  will  be  attacucd.  As  In  BASTS/1,  we  have  no 
conflict  with  the  scope  of  an  otherwise  part  since  there  are  no  nested 
uses  of  the  if  instruction. 


4.6  Validity  Checking 

In  both  the  translator  and  the  Interpreter  validity  tests  are 
frequently  applied  to  the  program.  These  are  specified  by  the  must  and 


the  must  not  Instructions.  For  example: 


The  <declaratlon>  designated  by  dd  must  contain  <f txed>. 


or: 

The  -^basic-value^  deshfnated  by  livd  must  not  ccwitain  •<undefined*. 


In  either  case,  if  the  cxjndition  is  satisfied  the  original  souroe  program 


is  in  error  and  its  meaning  is  undefined.  Tlte  abstract  machine  stc^  in  em 
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machine  for  some  types  of  program  error. 


4.7  Dynamic  Macro 


In  both  translator  and  interpreter  operations  it  often  happens 
that  one  of  a set  of  very  similar  cases  is  chosen  depending  on  the 
type  of  node  being  considered.  This  could,  for  example,  be  written  as: 

Step  2. 

Case  2.1.  cxs  is  an  (if-statcinent>. 

Perform  cmatje-if-statcinent(c3cs)  to  obtain  an  <if-statatent>,  axs. 
Case  2.2.  cxs  is  on  <assiqrmcnt-statoment>. 

Perform  ci'caLo-nssiqmrnt^statcmentlcxs)  to  obtain  an 
<assiqnmRnt-staUjnent>,  axs. 


Case  2.6.  cxs  is  a fwrite-stataTvent>. 

Perform  create-write-statanent(cxs)  to  obtaip  a te- 
sta tenent>,  axs. 


To  avoid  this  rather  lengthy  case  enumeration,  a so-called  "dynamic 
macro"  instruction  is  used  and  the  above  step  is  written  as  follows: 


Step  2.  Perform  create-xxx-stateraent  (cxs)  to  obtain  an 
■ixxx-statement:* , axs,  where  -^xxx-statement^  is 
the  type  of  cxs. 


f Thus  the  use  of  "xxx"  is  analogous  to  the  character  string  matching 

I 

t 

s and  substitution  commonly  used  in  macro  assembler  languages. 


J 
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5.  INFORMAL  DESCRIPTION  OF  SAL 

A definition  of  SAL,  a very  small  language  of  no  practical  valve,  will 
be  used  bo  demonstrate  the  DASIS/1  method  of  language  definition.  The 
following  is  an  exanple  of  a program  written  in  SAL: 

DBCIARi;  I FIXED, 

J, 

n niT; 

I = 2; 

TDF:  READ  irnOCA,  L)  ; 

IF  A I 

TIICJ  J = T; 
n,SE  J = A » T; 
imiTF  FROM  ( J)  ; 

1 = 1+1; 

IF  R 

niEn  no  m tdp; 

retito:; 

11®; 


A program  in  SAL  is  a list  of  statements  terminated  by  an  end-statement. 
Apart  from  the  end-statement,  there  are  assiirment,  conditional , decleuration, 
go-bo,  read,  rebum,  and  write  statements.  Like  PL/I,  there  are  no  reserved 
words  in  the  language.  The  distiix:tion  petwe'en  keywords  and  identifiers  is 
made  solely  on  context. 


5.1.  Variables 

Variables  may  be  declared  in  a non-executable  declare  statement  that  can 
occur  cinyvhere  in  the  program.  One  of  tJie  two  attributes,  FIXED  or  BIT,  may  be 
given  to  a variable.  Fixed  varialdes  take  positive  or  negative  integer 
values  and  hit  varialdes  take  values  0 or  1,  nieaning  false  or  true  respectively. 


If  a variable  is  not  declared,  an  im(dicit  declaration  for  it  is  constructed. 

In  the  alxjve  cxaj;|de,  dicrc'  is  no  ileclaration  for  the  variable  A and  it  will 

t 

i 

: \xy  infdicitly  declared.  If  a variaJde  is  not  given  an  attribute  in  a declciration, 

> like  J in  tlie  writb^n  ileclaration  anil  A in  tlie  constructed  declaration,  it  will 

i 

j receive  tJic  attribute  FlXIb  by  default.  'Itius  both  A and  J will  be  FIXED  variables. 


r 
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5.2.  Assiqment  Statanents  and  Eigaressiczis 

Ihe  execution  of  an  assignment  statement  causes  t±ie  evaluation  of  an 
e xpression,  producing  either  a fixed  or  bit  value.  This  value  is  tlien  assigned 
to  the  variable  referenced  on  the  left-hand  side  of  the  equals  syntol . The 
type  of  ttie  value  must  match  the  attribute  of  the  variable  to  vhich  it  is 

assigned,  i.e.,  there  is  no  type  conversion.  An  esq^ression  may  be  a constant,  ; 

as  in  I = 2;,  a reference  to  a variable,  as  inJ  = I;,  a prefix  expression,  ^ 

an  infix  expression,  as  iriJ=A*I;,ora  parenthesized  expression.  The 
prefix  and  infix  expressions  are  restricted  to  operands  that  have  integer 
values.  The  prefix  expression  uses  the  negation  operation  and  the  infix 
expression  offers  a choice  of  addition  and  multiplication.  These  operations 
have  the  normal  precedence  and  parentheses  may  be  used  to  change  it  in  the 
usual  way.  In  the  event  of  overflow,  the  effect  is  inpl anentation  defined.  It 

I is  an  implementation  decision  whether  the  program  is  abnormally  terminated  or 

I 

an  inpl enentation-de fined  value  is  produced.  Constants  Ccin  be  either  decimal 
representations  of  integers  or  bit  values  represented  by  "OB"  cmd  "IB". 

5.3  Ounditional  Statanents 

The  oonciitional  sLatcinc.-nt  is  of  a conventional  IP-THEN-optional-EI^E 
form.  The  then  and  else  i>arts  may  only  lx?  single  statements  and  may  not  be 
cinother  ccxiditional  , Tlx?  IcKjical  expression  may  be  either  a reference  to  a 
bit  variable  or  a oortparison  between  the  integer  values  of  two  expressions. 

Both  the  Gfiuals  and  nob-r^quals  conparisons  are  available. 

5.4.  Latiels 

Any  executable  statanent,  except  the  then  and  the  else  parts  of  a 
conditional  stabanent  may  have  a label.  In  the  exaiiple,  TOP;  is  a statement 
label.  The  go-to  statement  causes  control  to  be  transferred  unconditionally  to 


the  named  statement. 


•4r 
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5.5.  Input  and  Oatput 


The  input  and  cxitput  statements  interact  with  a pair  of  files.  The 


input  file,  consisting  of  a list  of  integer  and  bit  values,  is  read 
sequentially  by  the  read-statement.  In  executing  a read-statement 
values  from  the  input  file  are  assigned  to  the  variables  in  the  read- 
statement's  list,  in  left-to-right  order.  The  type  of  the  value  read 
must  match  the  type  of  the  variable  to  which  it  is  assigned.  It  is  an 
error  leading  to  abnormal  termination  for  a program  to  read  beyond 
the  end  of  the  input  file.  The  output  file  is  initially  empty  and  the 
write-statement  appends  integer  and  bit  values  to  it. 


5.6.  The  Return  Statement 

Execution  of  the  return-statement  causes  normal  termination  of  the 
program.  If  thare  is  no  return  statement  iiimecliately  before  the  endr-statement, 
one  is  assuned. 


Having  described  the  BASIS/1  definition  mechanism  and  informally 
described  SAL,  the  latter  part  of  this  paper  will  present  a formal 
definition  of  SAL  in  terms  of  the  mechanism.  To  illustrate  the  workings 
of  the  definitional  process  and  the  trees  that  are  constructed  by  the 
Translator  and  Interpreter,  we  make  use  of  an  example  SAL  program,  the 
so-called  "running  example."  The  running  example  is: 


DFXZLAHT:;  Y BIT, 

Z; 

READ  INTO  (Y,  Z) ; 

IF  Y TmU  X = 2*Z  + 1; 

EISE  X = 0; 

WRITE  FROM  (X) ; 
tit); 
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Hence,  the  rest  of  the  paper  will  consist  of  the  following  parts: 

(1)  Initialization  of  the  Abstract  Machine. 

(2)  Definition  of  the  parser  operations  for  SAL. 

(3)  Parsing  the  running  example  to  produce  the  concrete  program. 

(4)  Definition  of  the  constructor  operations  for  SAL. 

(5)  Construction  of  the  running  example's  abstract  program. 

(6)  Definition  of  the  interpreter  operations  for  SAL. 

(7)  Interpretation  of  the  running  example. 

The  definitions  of  the  three  syntaxes  for  SAL  will  be  interspersed  in 
appropriate  places. 

7.  miTIALlZATION  OF  THE  ABSTRACT  MAOIINE 

In  tills  section  we  descrilje  the  initialization  of  the  abstract  machine 
wliich  takes  place  at  tlie  IxKjinning  of  tlie  definition  process.  First  we  give 
tlie  syntax  rules  wliich  define  the  ■<machino-state>  during  the  translation 
of  the  character  string  representation  of  the  SAL  program  into  its  abstract 
program  n(|ui valent.  We  then  give  the  alonrithms  that  control  the  definition 
process . 
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7.1.  State  of  the  Abstract  Machine  Durii»3  Translation 


Ml.  •«nadune-state>  :;=  <program>  -^oontrol -stated 


[■<translation-state»  I -^interpretation-state^] 
M2,  -^oontrol -stated  -toperation-Ust^ 

M3.  -<trans1  ation-state>  ::=  [<program}>] 

M4.  -toporaticn^  ::  = 

Tlie  exact  structure  of  -^nporation-^  is  loft  unfonnalized  cind  unspecified. 
During  translation,  the  -^lach  ine~state»  contains  a < translation- stated 
ocn^nent. 


The  translation  phase  consists  first  of  reading  and  parsing  the  source 
program  to  form  the  <:prDgram>  aomponent  of  the  •< translation-stated.  The 
l:program>  is  then  translated  into  its  abstract  form  which  is  attached  to  the 
<program>  ccnponent  of  the  ■<madiine-stated. 


7. 2 Machine  Initial ization 

To  begin  the  definition  process  the  abstract  mcclune  is  given  the  following 

initial  -^chine-stated  tree 

-<machine-sta  bed : 

<progran> 

-<oontro  1 -stated: 

■toperation-l  istd : 

■^operationd  for  define-program  ;; 

■<  trans  1 ation- stated . 

At  this  point,  since  the  -^operationd  for  define-program  is  the  ri^tmost 
OTx^ration  of  the  -^opcration-l  istd , def  ine-progran  beccres  the  active  operation 
anfl  the  alBlxact  irvjchinc  starts  tn  execute  it. 
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7.3.  The  De fine-program  Operation 

( 

This  is  the  top-level  algorithm  tliat  controls  the  v^le  definition 
process. 

Operation:  de  f ine-program 

Step  1.  Perform  translation-parse-phase. 

Step  2.  Perform  translation-oonstruction-Dl-iase. 

Step  3.  Perfonti  interpretation-piiase. 


'fhe  translation-pars<?-phi.i3e  o;x' ration  reads  and  parses  the  source  program, 
Uie  translation-oonstruction-phaso  ofKration  treuislates  the  concrete  program 
into  its  abstract  form,  aixl  the  interpretation-phase  operation  interprets 
the  abstract  program. 


7.4.  The  Running  Exam}:)le 

The  execution  of  Step  1 in  tlic  dofine-progran  operation  changes  the 
■<nachine-state>  tree  to  that  sho^/n  in  Fiqiure  6.  At  this  point,  trainslation- 
parso-rhase  is  the  actave  or* ration. 


■^iiacl  li  n('-r,  tate> 


<f)roqreim> 


■^cmnLrol  -statc> 


•<transl  ation-state> 


■<operation-l  ist-> 


•<orx'ration> 

for 

de  f i ne-pr  eq  mn 


■<onoratlon» 

for 

traasl ation-parse-phase 


Figtire  6.  -^nachinc— stated  on  executing  Step  1 of 

He f i ne-proqram . 
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B.  Tip^  cr)^^RE^T:  synTuc 

The  ooncrete  syntax  of  SAL  specifies  the  written  form  of  the  language 
and  also  the  concrete  tree.  The  concrete  syntax  is  divided  into  t>K)  parts,  a 
la’^-level  syntax  and  a high-level  syntax.  T!ie  iCT^lGvel  syntax  classifies 
sequences  of  dioraetors  fmn  tiio  written  form  of  the  nrogran,  the  "text",  into 
non-delimiters  (wliicli  ore  \gDrcls  and  constants)  separated  by  delimiters.  The 
Iiiqh-lcvel  n^mtax  dc.'fines  tlie  way  tliat  a program  is  Ixiilt  fren  delimiters  and 
non-delimiters.  'Hie  sei:)aration  of  the  concrete  syntax  into  tivo  parts  is  done 
to  facilitate  the  context-sensitive  raiKoval  of  blanks  and  the  separation  of 
words  into  identifiers  cind  keywords.  Because  SAL  does  not  have  reserved 
words,  keywords  must  be  distinguished  from  identifiers  purely  on  the  basis 
of  context. 

B.l  The  Low-level  Syntax 
Syntax  for  text 

LLl.  ftext^  ::=  [fdel  imitcr-list>]  ^de limiter-pair-1  is t^ 

LL2.  f:delimiter-pair>  : :=  <:non-del imiter>  <delimiter-list> 

LL3.  fdolimiter>  + I*|-I-I4=l(l)l,l;|:lb 

Note:  "y5"  denotes  a blank. 

LL4.  fnon-del  imiter^  ;:=  {identifier^- 

I {oonstant> 

Syntax  for  identifiers  and  constants 

IJL5.  {identifier^  ::=  {letter  ^ 

I {identifier^  {{letter^  | {digits} 

LI,6.  {letter^  A | B I C | D I P | F 1 0 | II  | I | J | K | L I M | N 

I O I P I 0 I R I S I T I U I V I W I X I Y I Z 

rL7.  {digit  | 0 I 1 I 2 | 1 | 4 | S | 6 | 7 | B | 9 


LLb.  iconstant^  ;:=  tfixEd-oonstant> 


I tt>it-cxxistant> 

LL9.  j:fixed-oonstant>  ;:=  <ciigit-1  ist)" 

LLIO.  <bit-constant>  ::=  {O  I 1}E 

Syntax  for  characters 

The  input  to  the  definition  process  is  a {:chciracter-list>.  Hiere  are  47 

characters  in  the  SAL  character  set.  Each  character  of  the  <:character-list> 

that  rofjres€ints  the  program  being  defined  belongs  to  one  of  three  groups: 

digits,  letters,  and  delimiters. 

LLll.  <:character>  ::=  {digits 

I <letter^ 

I fdel  imiterj 


8.2.  The  High-level  Syntax 

The  goal  of  tlie  high-level  syntax  is  to  classify  sequences  of  delimiters 
and  non-del  imiters  into  units  which  oorrespcxid  to  SAL  statements. 

Syntax  for  program 

IILl.  {:profjram|>  funit-list>  <ond-stateinent> 

1IL2.  funit)*  ::=  <declarc^stat£aix^nt> 

I ^^ex(!ciital)li  — iin  it^ 

Hl.J.  <«.Tki-;;tatllTK'nt^  n'JD  ; 

Syntax  for  declarations 

HL4.  <declaro-statoment>  ;:=  DlJCLARl’.  tdeclaration-oofimal  ist>  ; 

1IL5.  {d€K:laration|>  ::=  Cidentifier^  [^attriliute^] 

IILf).  fattriljute^  FIXiJD 

I HIT 


Syntax  tor  ex('cutal)U^-i.uuts 


[{stataient-nane^J 
{<i  f-statoiTient> 


fexecutable-singl e-statement> ) 


(11.7.  <cx'>cutal>l(‘-unit> 


w . 
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HL8.  <:statenent-nane> 
HL9.  <:if-statement>  : 


:=  |:identifierV 


IF  <logica1-expression> 

TUTU  iexecutable-single-statement> 
[eL£E  iexecutable-sing1e-statenent>] 


Syntax  for  singl  e- statements 


ULIO.  <:executable-single-statanent^  ::=  <assignment-statement> 

I <:goto-statjanent> 

I fread-statenient> 

I fretum-statement> 

I <:write-statement^ 


HLll. 

fassigrment-statatent^ 

::=  {identifier^  = 

{expression^  ; 

HL12. 

i:goto-stateinent>  ;:  = 

GOTO  {identifier>  ; 

HL13. 

<read-stateinent>  ;:= 

READ  INTO  { {identifier-comial  ist>  ) 

HL14. 

fretum-statement^  : ; = 

= RETURN  ; 

IIU5. 

<:write-statement>  : := 

WRITE  FROM  ( {identif  ier-oonmal  ist> 

Syntax 

for  expressions 

HL16. 

{logical -expression ^ ; 

:=  {identifier)* 

1 {expressionj  {=  I 

^ ) {expression> 

HU7. 

{expression^  ;:=  [{expression^  +]  {expression-tws^ 

IIL18. 

{expression- two^  :;= 

[{expression- two^  *] 

{expres  sion-  one> 

HL19. 

{e:^ression-one>  ::= 

1 

1 

{primi  tive-express  ion> 
- {expression-one> 

( {expression^  ) 

HL20. 

{primitive-expression^ 

: :=  {identifier> 

<:c3onstant> 


9.  710;  'lyAtaSIiATOR  (PARSE  PUftSE  ) 

The  function  of  the  parse  phase  of  the  translator  is  to  take  the  character 


list  representation  of  the  S/VL  program  and  generate  a corresponding  concrete 
progran.  The  parsing  is  performed  in  tvo  stages  corresponding  to  the  two 
levels  of  the  ooncrete  syntax. 


i 
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I 9.1  The  Operations 

Operation:  trans  1 a tion-pcirse-f^ase 

^ Step  1.  Obtadn  fropi  a source  outside  this  definition  a sequence  of  characters 

constructed  in  the  form  of  a f character-! is t^,  cl. 

Step  2.  Perform  parse(cl)  to  obtain  a <:program>,  cp. 

Step  3.  Attach  cp  to  the  ^tr6mslation-state>. 

OTTcration:  t^arse  (cl ) 

•hero:  cl  is  a fcharactcr-1  i.st> 
resul  t:  a i:prr)qran> 

Step  1.  I’orform  low-lcvol-jvirso  (cl ) to  obtain  a <tfixt>,  tx. 

Step  2.  Perform  hirj)i-lovel-pirse(tx)  to  obtain  a <r)roqram>,  cp. 

Step  3.  Return  cp. 


Operation:  lo/- level -parse  (cl ) 

wliere:  cl  is  a tcharacter-1  ist> 
result:  a <t<a<t> 

Stef)  1.  There  must  exist  ore  and  only  one  tree,  tx,  with  respect  to  tlie  lew- 
level  syntax  for  <:text>,  such  that  the  terminal  nodes  of  tx,  taJeen 
in  left-to-riqht  ordex,  form  a <character-l ist>  equal  to  cl. 

Step  2.  Return  tx. 

A keyword  is  an  iidentifiex>  which  majTS  into  a tj^pe  specif itjd  in  the  high-level 
syntax  by  exj)!  ici  t siK'llin'f  witliout  .any  mctaJirackots. 

The  followinr}  is  a pnxluctlon  For  a type  that  is  used  solely  in  the  following 

operation  anti  is  tints  s])ecificKl  hero  rather  than  in  the  concrete  syntax; 

fdel  imiter-ar-non-del  imiter>  ::=  Welimiter^ 

I <nDn-del  imi  ter> 

Operation:  high-1  evel -par  so  (t:<) 
where:  tx  is  a tbext> 
result:  a tr)mgram> 

Step  1.  let  t lx?  a idelimiter-or-non-dolimiter-list>  which  cxxitains  a ccjpy 


of  tlie  <:delimiter>  and  bion-delimiter>  cerronents  of  tx  in  exactly 
tlie  same  order. 
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Stjep  2. 
Step  3. 
Step  4. 


Case  4.1.  nht[jL]  is  a keyv*rard. 

The  node  nt[i]  must  be  an  <identifier>  containing  the  sane 
terminals  as  the  characters  appearing  in  nht[i]. 

Case  4.2.  nht[i]  is  an  ^identifiers  oa:  foonstantS. 

The  ncxJes  nt[i]  and  nht[i]  must  be  of  the  same  type.  Replcice 
nht[i]  by  nt[i]. 

Case  4.3.  nht[i]  is  a non-bracketed  type  other  than  a keyword. 
nt[i]  and  nht[i]  must  be  equal. 

Step  5.  Return  ht. 


9.2  Application  to  the  Running  Example  ' 

The  Paurse  Phcuse  of  the  Translator  is  illustrated,  first  by  taking  part 
of  the  character  representaticn  of  the  Running  Example  throu^  the  low-level 
parse  and  then  showing  the  build  ip  of  the  entire  program.  Figure  7 shows 
the  situation  at  Step  1 of  translation-parse-phase.  The  section  of  the 
Character- lists,  cl  that  correspcxids  to: 

IF  Y THEN  X = 2*Z  + 1; 

is  stown  with  each  cheuracter  classified  as  a <:ietterS,  fdigitS,  or  WelindterS 
aooording  to  the  syntax  for  characters  LLll. 

ftr  t j ’ r*  11 3 1 ► 

m — r~i — I — n — i — n — I — i — i — i — rn — i — \ — i — i — i — i 

(c>  irt  > fo  (I  > fr>  t'  > <rt  try  try  (cy  try  to  (cy  tcy  (O  tcy  tcy 

I I I I I I I I I I I I I I I I I I I I I I 

i:i.>  r.>  t'>  ti  > ti  y r.y  t^y  to  t^y  tp>  P^y  fT>  to  t^y  to  to^  t^y 

I I I I I I t I I I I I I I I I I I I I I I 

1FXY)STMENXXK->I2*ZK  + I«1! 


rrprrYirntji  tftwu'nrtr'rV,  tT.)  mnrt-'.mtn  tlcttcrt,  tn>  rrpre^pnta  tdif3it>y 
onl  p^y  t' ''’limi trrt. 

A hmknn  ooimrr-Linrj  linn  imlicntm  the  emission  of  one  or  nore  nodes. 

Figure  7.  Part  of  the  ^character- lists  representation  of  the 
Running  Example. 


L 


Delete  from  t any  fdelimiterS  containing  a ")6".  This  must  not  cause 
t to  be  deleted. 

Let  nt[i],  i = l,...,n  be  the  ordered  list  of  nodes  iihich  are  the 
immediate  oemponents  of  the  iCdelimiterS  and  <non-deliiniterS  nodes  of  t. 
There  must  exist  one  and  only  one  tree,  ht  vrhich  is  a oarplete  tree 
with  respect  to  the  high-level  syntax  for  ^programs  such  that  ht 
contains  terminal  nodes  nht[i]  i=l,...n  and  there  is  a one-tD-<*»e 
correspondence  between  nt[i]  and  nht[i]  as  specified  by  Cases  4.1 
through  4.3. 


The  result  of  applying  the  operation  low- level -parse  to  this  l^diaracter- 
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1ist>  is  to  obtain  the  itext>  tree  which  consists  of  a {:de1iiniter-pair- 
1ist>  as  shown  in  Figure  £L  The  section  of  <:text>  that  is  shown  there 
corresponds  to  the  same  section  of  the  teharacter-1ist>  that  was  shown 
in  Figure  7. 

The  operation  high- level -parse  constructs  a <delimiter-or^non- 
deliniiter-list>  that  matches  the  fdelimiter^  cind  then-del imi ter > oonponents 
of  the  ftext>.  The  secticai  of  the  tdelimiter-or-non-delimiter-list^  that 
is  derived  from  the  part  of  <text^  shown  in  Figure  8 is  shown  in  Pigxjre  9a. 

In  order  to  save  space,  the  trees  for  tidentifierj  and  <constant>  are 
represented  by  their  root  and  tenninal  nodes  only.  The  next  step  is  to 
ratiove  the  blanks  fron  the  tdel  imiter-or-non-del  imiter-l  ist>.  The  result  of 
this  is  shown  in  Figure  9b.  The  correspondence  between  elements  of  the  vector 
nt  of  Step  3 and  nodes  of  the  <del  iraiter-or-non-del  imiter-list^  is  also  shown. 

Th(?  high-level -parse  continues  wltli  the  construction  of  a tree  according 
to  the  high-level  syntax.  Step  4 constincts  this  tree  with  a f program^  root 
node,  designated  by  the  local  variable  ht.  Its  terminal  nodes  cure  either 
^identifiers,  or  fconstant>  nodes  or  else  delimiters.  These  terminal  nodes 
must  match  in  left^to-right.  order  tiie  nodes  of  the  fdel  imiter-ar-non-del  imiter^ 
list>.  Figure  lOshcws  the  section  of  the  <prograni>  tree  ht  that  corresponds 
to  the  section  of  the  {del  imiter-or-non-dcl  imiter-list^  of  Figure  9b.  The 
elanents  of  the  vector  nht  of  Stef>  4 that  desiijnato  nodes  in  the  figure  are 
also  sfiown. 

It  is  at  this  point  tJvit  tlie  distinction  is  made  between  keywords  and 


program  identifiers  ^ultl  tlie  specific  details  for  each  l^identifier^  and 
♦:cDnstant>  are  filled  in.  This  results  in  the  ♦:program>  tree  section  shown 


<Jc<d>  {Jnd>  fdc«:>  Coci»J>  {j.rc>  t±lrri>  {dor^i>  toor^^  |:QOnc;>  CJor.a>  taona>  {dDr,u> 
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Figure  9b.  The  section  of  the  i:de1iinitej>-<3r-nDn-cle1iitd.ter-list>  shown  in 

Figure  8a  after  removal  of  blanks. 


tuiut-tist> 


r ^ 

in  Figure  H This  is  done  by  the  three  cases  of  Step  4.  Case  4.1  applies 
vtere  an  element  of  nht  cSesignates  a keyvord.  For  exanple  nht[15]  xaesignates  the 
keyword  IF  and  nt[l5]  designates  an  ^identifiers  containing  IF.  Case  4.2 
applies  where  elements  of  nht  designate  ^identifiers  and  <:oonstantS  rodes. 

Ftor  exarple,  nht[l8]  designates  an  (identifiers  and  nht[20]  designates  a 
(constants.  For  these  nodes,  the  (programs  tree  is  oratpleted  hy  cofying 
the  details  fron  the  (delimiter-or^non-delimiter-listS,  in  these  two  cases, 
copying  the  sybtrees  of  the  nodes  designated  by  nt[l8]  and  nt[20]  respectively. 

4.3  ensures  a match  between  delimiters,  for  exarple  nht[22]  and  nt[22] 
both  designate  an  asterisk. 

( 

Ihe  (programs  tree  shown  in  Figure  11  is  a section  of  the  omtplete  concrete 
program  of  the  running  example.  Onoe  it  heis  been  constructed,  the  (programs 
tree  is  attached  to  the  4tramslation-state>  as  indicated  in  Figure  12  . 


10.  THE  ABSTRACT  SYNTAX 

The  abstract  syntax  cteliberately  beeurs  a strong  resarblcinoe  to  the 
corresponding  parts  of  the  concrete  syntax.  Ihe  relationship  between  these 
parts  is  intended  to  be  intuitively  obvious.  Ihe  main  difference  is  that 
those  parts  of  the  concrete  syntax  whose  only  function  is  in  the  written  form 
of  the  program  have  been  emitted  in  the  abstract  syntax. 

Syntax  for  programs 

Al.  <program>  : :=  [ <decl oration- 1 is t>l  [ <executabl e-uni  t-1  is  t>] 


.Syntax  for  declarations 

A2.  <declaration>  <idnntifiGr>  <attributo> 

A3.  <attril)utc>  ;;=  <fixc(l>  | <bit> 


furut-1i3t>  tent}-*tktEr«t» 
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Figure  H-  Section  of  completed  tprogran^  tree  matching  the  part  of  the  tdelimi 
non-deliinitEr^1ist>  shown  in  Figure  8b. 


i 


I 

► 


r 

f 
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Syntax  for  executable-units 

A4.  <executabl  e-uni  t>  ::=  [<statEnient-nanie>] 

{<if-statenient>  | <singl  e-statErient> } 

A5.  <stat£3nent-name>  ::=  <idGntificr> 

Syntax  for  if-stntGpr?nt.s 

A6.  <if-statcJTK?nt>  ::=  <loqical-oxyirr'.Tsion>  <then-unit>  [<e1  se-unit>] 
hi,  <tiien-unit>  ::=  <3inij1r'-r.tatcinnnt> 

A8.  <ol.3o-iinit>  :;=  <;iirK7  •i“Stntr5Tior;t> 


Syntax  for  single-statanents 

A9.  <single-statement>  ;:=  <assignment-statement> 

I <gotD-staterEnt> 

1 <read-statjenent> 

I <retum-stat£n>ent> 

I <write-stateinent> 

AlO.  <assigninent-statement>  ::=  <variab1e-referenoe>  <expressiDn> 

All.  <qDto-statanent>  <executab1o-unit-designator> 

I <identifier> 

A12.  <read-stat£3Tient>  ::=  <variablo-referc*noe-l ist> 

A13.  <write-statanc!nt>  ::=  <variabl e- reference- list> 


Syntax  for  expressions 

A14.  < logical -exp ression>  ::=  <expiession>  {<eq>  | <ne>}  <expression> 

I <variable-reference> 

A15.  <expres3ion>  ::=  <v^u:iablo-referenc{^> 

I <constant> 

I <infix-cxfircssion> 

I <prefix-exi5rossion> 

A16.  <inf ix-expression>  <cxpression>  {<add>  I <mul tipi y>}  <expression> 

A17.  <prefix-cxf5ressiDn>  ::=  <minus>  <expression> 


Syntax  for  references 


A18.  <variahjlc-refcr(^nce> 


<decl aration-dcsiqnator> 


r 

')0 

A19.  <identifier> 

<uk;ntifier>  is  deii-rvxl  as  a tsymbol-l ist>  correspondiryj  to  the  sequence  of 
• characters  in  {identifier>. 

[ 

I 

! Syntax  for  constants 

A20.  <cQnstant>  : 4jLnteqor-value> 

I 4bit- valued 

An  -<inteqer^value»  is  a -^machiru^-stitf^  (defined  in  Section  12,  rule  M13, 

tliat  contiii^s  a simile  olnrk  nt  U''.'  :>el:  of  inteqers.  A ^bit-value^  is 
defined  in  rule  M12  ana  ctjntiitvs  one  of  the  values  •<true»  or  ■<fa1se». 


11.  IHE  TRANStAlOR  (CONSTRUCTION  PHASE) 

The  portion  of  the  definition  algorithm  described  in  this  section  first 
expands  tl*e  ccncrete  tree  by  afipl  ying  the  defaults  and  then  constructs  the  abstract 
program  con^xarent  of  the  -^maclune- stated.  During  tlie  construction,  checks 
are  made  for  caitext  de|x>n>ient  errors. 

oix-ration:  i uri-^ajii^.u  ucl  Lon-pluui<' 

Sb'p  1.  I'erlonn  !X)iti()l('ti  vHUK'n't.— eif vir.iin. 

Sti!p  2.  F'-rform  v.il  idat<'-M)i;<-rcU-— >«■>•). 

Jtrfon'i  <Te.)0— 

4.  Ueletc  tlK-  -ttrntisl  ii  i')ii-sKite>  1 nxii  tJie  -^nvichine-state^. 

11.1  Rxpa riding  tfie  Concrete  lYec 

TTve  operations  of  tills  section  add  oonponents  to  the  ^progranj  corresponding 


to  ittfilicit  dtx:l^u:at ions,  attrilrtitc  tlefaults  and  tlie  terminal  return  statement 


!)1 


Operation:  oomplete-ooncaretg-prograni 

Step  1.  Perform  implicit-declaration. 

Step  2.  Perform  attribute-default. 

Step  3.  Let  ul  be  the  <:unib-list>  of  the  <program>.  If  the  rightrmost 
{executabl  e-uni t>  ocnponent  of  ul  does  not  iimediately  contain 
texBcutabl  e-singl  ©-statement^: 

<retum-s  tatEinent> ; 
then  append  to  ul 
|:vinit>: 

fexecutabl e-uni t> : 

<executabl  e-sing  1 e-s  ta  tement> : 
f retum-s  ta  tement> 

RETORN 


Operation:  impl ici  t-decl aration 

Step  1.  Let  ul  be  the  i:unit-list>  of  the  {:program>. 

Step  2.  For  each  <identifier>,  id,  contained  in  am  <executabl e-uni t>  of  ul, 
perform  Step  2.1. 

Step  2.1.  If  id  is  not  contained  in  a istatemenb-name>  or  <:gotD-stateroent> 
and  if  there  is  no  l^declaure-statanentj  that  contains  id  then 
attach  to  ul 

{decl  are-s  tataiient> : 
declare 

idecl  aration-canmal  ist> : 

<(leclaration>: 
id  ;; 

C;>. 


Operation:  attribute-dofaul ts 


Step  1.  Let  ul  br  tiio  {:unit-Ust>  of  tJie  fprogram^  . 

Step  2.  For  each  ^declaration^,  d contained  in  ul , perform  Step  2.1. 
Step  2.1.  If  d does  not  contain  an  <attribute>  then  attach 
I'TXT'n  to,  (i. 


11.2  Analyzing  Declarations 

The  operation  in  tliis  section  checks  tliat  no  identifier  is  declared  more 


than  oner. 

Operation : val  idati>-concrct/wloc1arations 

Step  1.  The  fjirograin^  miL'-.t  mt  contain  two  or  more  (declaration^  nodes 
whose  (ick'ntilierl-  ajnrxononts  arc  equal. 

Step  2.  Tin*  (pr(j<|r.«n^  must  rK>t  contain  a (declaration^  that  has  an 

(identifier^  tint  is  cxiiul  to  an  (iilontif ier^  contained  in  a 
(staUmcnt-iuini'K 


I.’ 


k 


11.3  lA*ilk  the  Abiitr.net  Tree 

The  operations  of  .his  section  construct  and  attach  to  the  abstract 
<program>  an  abstract  <executable-unit>  or  <declaration-unit>  corresponding 
to  each  <unlt>.  Declarations  are  translated  before  executable-units  to 
facilitate  the  buildinp,  of  designator  nodes.  Since  a <goto-statement>  may 
contain  a Uirward  ri’f iTci:;  j , llie  final  operation  is  to  resolve  the  statement- 
name  releriMices  in  the  • gel  o-s  I a t i-ment>  and  replace  them  by  <executable-unit- 
des Ignat  oc's . 

Oi'oratio! i : cio-ati.  - pit )')r.ini 

Step  1.  Lc;t  ol  Lo  t.nc'  fanit.  - 1 ird  1-  an  the  ^program}*. 

Step  2.  For  each  t .’eclat at  iotil,  ).  c'DiUninexl  in  ul , ixnrfonn  create- 
abr.  trac  t-cV„‘c  t -,ir £i  t it  >r.  ( t i ) . 

Step  3.  For  each  f e:-:e'ai|  in!.  -u,  c-anLainod  in  ul , taken  in  left- 

to-rirjht  ortlei  , (xrfonn  '.x)nstr'jct-ab.stract-stataTient{e  u) . 

Step  4.  Perf'or.i  o)irq  loto— jotos. 


Oix'rat.t  >11..  It  (i^'t  hii^'  ■ "j 
' 't » 't.)  ti  on ; tn  I 'at  I ’.>  ' • > i !■ ' '1  ai  .P  > o>i i-,  I) 

\;1 1.  '•■>  ; •'<1  in  i ! ■ i ‘ i • , a i ' i .nt 

.Step  1.  l,ot  ri'l  i-  I'lo  i -t  l-  < < o'.  Perform  create- identi f icr{od)  to 

ohlxiiri  .(!!  <i'i(  lit  1 f I'-r'',  ill. 

St£'p  2.  rr  crl  (T.nta  in;-;  rit-T  ii  tlioM  i-d  .pi  Ix'  <f  jxotl>,  otherwise  let  atr  be  <bit>. 
Stet)  1.  Anrx^'iil  a 

^rleclar.i ' ion.'-; 
i<! 

<. P ' r j : HI t ' ■ > ; 

)t  c. 

tx)  til-'  <*‘rc«ir,j;''>. 
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Step  1.  If  ce  ijmrdiatjcly  contains  an  <executabl e-sing le-stateinent}»,  ess, 
then  let  cxs  be  tlto  irrrcdiate  component  of  ess,  otlierwise  let  cxs 
be  the  immediately  contained  ♦:if-statanent>  of  oe. 

Step  2.  Perform  crcate-xxx-stabement(cxs)  to  obtciin  an  <xxx-staterient> , axs, 
where  cxs  is  an  i:xxx-statanentl>. 

Step  3.  Let  eu  be  an  <executabl e-unit >.  Attach  axs  to  eu. 

Step  4.  If  oe  contains  a l:stataiient-name>  then  perform  Steps  4.1  and  4.2. 

Step  4.1.  Let  cid  be  the  ^identifiers  immediately  contained  by  the 
l:statement-nciTeS  of  ce.  Perform  create-identifier  (cid) 
to  detain  an  <identifier>,  id. 

Step  4.2.  Attach  id  to  eu. 

Step  5.  Append  eu  to  the  <proqram>. 


Operation:  creato-if-staUanent  (ci£) 

whore:  ci  f is  iut  fif-sUitimcntS 
resul  t:  an  <if-statcJTient> 

Step  1.  Let  cle  be  the  (lofjical-exj'rc^ssionS  contained  in  cif.  Perform 
create-logical -expression (cl e)  to  obtain  a <logical -express iDn>, 
alx. 

Step  2.  Let  ess  be  the  leftmost  <:executabl e-singl e-statement>  contained  in 
cif.  Let  cxs  be  the  <xxx-stateiTientS  contained  in  ess.  Perform 
! create-xxx-statjemGnt(cxs)  tx)  dstain  cin  <xxx- statement,  axs. 

' Step  3.  let  aif  be 

i <if-statement> : 

i alx 

• <then-unit>: 

1 <sinqle-statcment>: 

axs. 

' Step  4.  If  cif  contains  LliJi.  then  i:x:rform  Steps  4.1  and  4.2. 

Step  4.1.  let  ess  bo  tie  rightmost  <executable-single-statenentS 
aontaine<l  in  cif.  let  cxs  be  the  fxxx-statarent^ 
j contained  in  ess.  Perform  create-xxx- statement  (cxs) 

1 to  obtain  on  <xxx-stabement>,  axs. 

J Step  4.2.  Attach  an 

<elsc-unit>: 

<single-statc3nent> : 
axs;; 

to  aif. 

Step  5.  Return  aif. 
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Operations  for  single  statanents 
Operation:  create-assignment-statenientCcas) 

vtiere:  cas  is  an  faasiynment-statement^ 


result:  an  <assiynrt!nt-statGiiient> 

Step  1.  Let  id  cind  cx  be  resjaectively  the  UTinediatel y contained  ^identifiers 
and  ^expressions  of  cas. 

Step  2.  Perform  fitxi-aljstr  act-declaration  (id)  to  obtain  a <dec1eu:atiDn— 
designator>,  lid. 

Step  3.  Perform  create-expression (cx)  to  obtain  an  <expression>,  ax. 

Step  4. 

Case  4.1.  ax  inrxKliatcly  oontciins  a <variabl e-ref erenoe>,  vr. 

Hie  <attii’'/uti.  oontaiiKxJ  by  the  <dec1au:ation>  designated  by 
(id  must  e-iual  till-'  <attribute>  contained  by  the  <declaration> 
desigrutod  by  tiic  <dcc1aration-designator>  of  vr. 

Case  4.2.  ax  iriuLvliate  I / ccntains  a <constant>,  c. 

If  c (.xjntains  •*tnUr}('r-valu^>  then  the  <decl aration> 
dcsiijn.itjed  by  dd  must  contain  <f ixed>,  otherwise  it  must 
contain  <bit>. 

Case  4.3.  (Otlxuvi se) . 

Tile  <.dcclaration>  (icsKjnated  by  dii  must  ccxitain  <fixed>. 

Step  5.  Return  an 

<assj  grj(r’nt-statciiient> : 

<var  i ai ) I . — ref  orcnce> : 
dd; 

lIX. 


Ofiora tion : create  got  o-sLi  '-em  rit.  ( o js ) 


v^^ieje:  c.'js  j..‘  c (s<j')tji.>-'-.tatciiinntS 


resi  l t;  i .'jobL»-stat  . su 'nt  > 

Step  1.  Let  cid  ix'  the  <iden '.if  j-  rS  ixinLained  in  egs  and  perform  create- 
iiientif  ler  (cid)  !jO  obbnn  an  < iilenti fier> , id. 

Step  2.  l^tum  i 

<if  )to-sL'  t<  iiir  ‘lit  > : 
id. 


Operation:  create-n-ad-statanent  (ers) 

where:  ers  is  .i  fii'ad-staijunnntS 

nisult:  a <n'.id-r;tab5Ticnt> 

Step  1.  lot  ars  tx-  a •dfa<l-stabm;nt>. 

Stop  2.  Let  idl  be  the  f identifior-conmalistS  of  ers. 

Step  3.  FOr  each  fidentif  ierl , id,  of  tdl , taJtcn  in  left-to-right  order, 
perform  Gteps  3.1  and  3.2. 

Sten  3.1.  Perform  find-alistract-ileclarationdd)  to  obtain  a 
<doc1tU'ation-»k'5.u/natDr>,  dd. 

Step  3.2.  AfTienl  <var iabU?-referenoe>:  dd;  to  ars. 

Step  4.  Return  ars. 

_ - -J 


1 
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Operation:  create-retum-statenent  (crs ) 

where:  crs  is  a {:retum-statanent> 
resul  t:  a <retiim-s  tatetnent> 

Step  1.  Return  a <retum-stataTient> « 


Operation:  create-write-statanent(cws) 

v^ere:  cws  is  a ^write-statement^ 

resul  t:  a <write-statanient> 

Step  1.  Let  aws  Le  a <write-stat£rient>. 

Step  2.  let  idl  Le  tlie  <iclcnUfier-aoninalist>  of  cws. 

Step  3.  For  each  l:ick?ntifi(!r}>,  id,  of  idl , taken  in  left-to-right  order, 

1 perform  Steps  3.1  anti  3.2. 

j Step  3.1.  Perfonn  find-abstract-declaration(id)  to  obtain  a 

‘ <cleclaration-<iosi(jnator>,  dd. 

Step  3.2.  A^jpend  <variable-rcforenco>:  dd;  to  aws. 

Step  4.  Return  aws. 

I 

I 

Operations  for  expressions 

Operation:  create-1 ogical -expression (cl x) 

where;  clx  is  a ♦:iogical-expression> 

result:  a <loqical-expression> 

Case  1.  clx  ijTinodiately  contains  an  {iclcntifierh,  id. 

Step  1.1.  PC!rform  find-alistract-declaration(id)  to  obtain  a <decl euration- 

rk‘signator>,  dd.  The  <declaration>  designated  hy  dd  must  contain 
<hit>. 

Step  1.2.  Return 

<1 ogical -oxprossion> : 

<varialil  o-rof  eronce> : 
dd. 

Case  2.  clx  has  three  ccitiponents,  cxl,  op,  and  cx2,  in  left  to  right  order. 

Step  2.1.  Perform  area te-operand( cxl)  to  obtain  the  <exDression> , axl. 

IVirform  create-operand(cx2)  to  obtain  the  <exDression>,  2oc2. 

Stop  2.2.  If  op  is  = thOT  let  aop  be  <eq>,  otherwise  let  cOp  be  <ne>. 

Step  2.3.  Return 

< 1 ogi ca 1 -express ion> : 
aucl 
aop 
ax2. 
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Operation;  create-exf^ression  (cx) 

where:  cx  is  an  <texpriession>,  <:expression-two>,  fexpression-one> , 
or  fi-irimtive-exprossionK 

result:  an  <cxriression>. 

Case  1.  cx  is  cin  ^expressions,  <cxnrcssion-twoS,  or  <exDression-oneS  and  cx 
has  only  one  canponent,  cxc. 

Perform  crGate-e^xf)rer>sion(cxc)  to  obtain  an  <expression>,  ax.  Return  ax. 

Case  2.  cx  is  an  texnressionS,  or  foxpression-twoS  and  has  three  oorponents, 
cxl,  copn,  antJ  cx2,  in  lef t-to-right  order. 

Step  2.1.  Perform  creato-opt.’raiKl(cxl)  to  obtain  an  <expression>,  axl. 

Perform  croate-operand  (cx2)  to  obtain  an  <expriession>,  ax2. 

Step  2.2.  If  oor>n  is  + tJien  let  aopn  l)e  <add>  otherwise  let  aopn  lie  <toultiply>. 
Step  2.3.  Return  an 

<expn^sion> ; 
axl 
aofTn 

; ax2. 

! Case  -3.  cx  is  an  ieig^ression-oneS  with  tup  conjonents,  copn  and  cxl,  taken  i,  (eft- 

; to- right  order. 

j Perform  create-  operarrl(cxl)  to  obtain  £in  <oxi)ression>,  ax.  Return  an 

! <exr>r('SGion> ; 

I <f’ref  ix-exr)ression> : 

, <minus> 

i ^ ax. 

[ Case  4.  cx  is  an  fcxiiression-oix’S  witJi  tliree  ocr^xxicnts,  cl,  cxl,  and  c2,  tiken  in 

■ left-to-right  order. 

[ Perform  croate-onerand(cxl)  to  obtain  an  <cxpression> , ax.  Return  cix. 

Case  5.  cx  is  a tprimitive-exT'TessionS  ani  contains  an  <:iftentif ier> , id. 

Perform  f ind-abstra' ■t“ri...\::laration(id)  to  obtain  a <declaration-designator>,  dd. 
Return  an 

''ext  >re.';s]On>: 

vvaiiatge-rLtf  ererrtv: 
dd. 

Case  6.  cx  is  a <:nrimi  ti  vo-exnrossion>  and  oontains  a CccxistantS,  c. 

Perform  crea*:'^non'dant  (e)  to  obtain  a <oonst.ant>,  ac.  Return  an 

d •;  :ifin>; 


Oper  ation:  create-operarK I (cx) 

where:  cx  is  an  faxprrssionS,  fexpression-twoS,  <:exDressiorr-oneS, 
or  fprimitive-exi''ressionS. 

result:  an  <exriression> 

Step  1.  If  cx  is  a tprimi tive-exoressionS  then  perform  Step  1.1. 

Step  1.1. 

Case  1.1.1.  cx  iiunediaUtlv  contains  ^identifiers,  id. 


l\irform  finr)-al)stract-dcclaration(id)  to  ctotain  a <decleLraticn- 
desiirrwitor>,  dd.  The  <dec1aration>  designated  by  dd  must 
contain  <fixed>. 
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case  1.1.2.  cx  iiinediately  contains  <oonstant^,  cn. 

Tlie  ^oonsteuit>,  cn  must  not  contain  {Isit-dDnstJ. 
Step  2.  Perform  create-expression(cx)  to  obtain  an  <expression>,  ar. 
Return  eu:. 


Utility  operations 

Operation:  create-identif ier (cid) 

v^ere;  cid  is  cin  ^identifiers 
resul t:  an  <identifier> 

Step  1.  Return  an  <identifier>  whose  concrete  representation  is  the  same 
as  that  of  cid. 


Operation:  find-abstract-declaration (cid) 

where:  cid  is  an  ^identifiers 

result;  a <declaration-designator> 

Step  1.  Perform  create- identifier (cid)  to  obtain  an  <identifier>,  id. 
Step  2.  Let  dl  be  the  <dec1aration-1ist>  contciined  in  the  <program>. 
Step  3.  Let  dd  be  a <declaration-designator>  for  the  <dec1aration 
containing  id. 

Step  4.  Return  dd. 


Operation;  create-constant ( cc ) 

where:  cc  is  a fconstantS. 
result:  a <constant> 

Case  1.  cc  inmcdiatel y contains  <bit-oonstS»  be. 

If  be  contains  IB  then  let  abv  be  <true>»  otherwise  let  abv  be 
•<false».  Return  a 

<oonstant> : 

<bit-oonst>; 

alv. 

Case  2.  cc  urmediately  contains  a {digit-1  istS»  dl . 

Let  iv  be  an  ^integee-value*  equal  to  the  value  obtained  by  interpreting 
tJie  {digitSs  of  dl  in  left-to-right  order  as  a decimal  integer. 

Return  a 

<constant>; 

iv. 
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Operation  for  goto  cleanv^ 

Operation : ocxnpl  ete-gotps 

Step  1.  Let  eul  be  tl-ve  <e»2cutabl e-unit-1  ist>  inmediately  contained  in  the 
<program>. 

Stop  2.  'TTicre  mist  net  lx?  two  or  more  offual  <statenent-name>  conponents  of  eul. 

Step  3.  For  each  <goto-stateinont>,  g,  oontaine<1  in  eul  perform  Steps  4.1 
through  4.3. 

Steo  4.1.  Let  id  be  tlx?  <identifier>  contained  in  q. 

Step  4.2.  Tliere  must  exist  in  eul  a <staterient-name>,  sn,  viiidi  contains  an 
<idcntifier>  equal  to  id. 

Step  4.3.  Replace  id  by  the  <executable-unih-desir^nator>  that  designates  the 
<executabl e-uni t>  oontaininp  sn. 

11.4  Application  to  tlio  Running  t^coargde 

The  first  stage  of  this  phase  of  the  Translator  is  to  oonplete  the  ' 

ooncrete  {program  by  constructing  a DICLARl:  statement  for  any  variables  that 
were  not  declared  in  tiie  original  program.  The  variable  X in  the  running 
example  was  not  de>clared  and  a declaration  with  no  specified  attribute  is 
constructed  for  it.  The  FIXED  attribute  is  then  included  in  any  DECLARE 
statement  witliout  an  attriinit*.'  siJ«?cii  ic<< . The  FIXED  attribute  is  therefore 
arified  to  the  f ieclai  stionf  tor  X just  rxDnstructod  and  to  the  l^decl aration^ 
for  Z whicti  had  no  attriiiute  ri'rd  ir  the  source  program.  Finally,  if 

there  is  no  final  RL'DJRN  stateiTrfnt  in  idie-  program,  one  is  ccxistructed  and 
afjpcnciid  fx)  the  {.unit-)  jsuK  Tlio  rer  ui  t of  conr/leting  the  ooncrete  program 
for  the  kunniiKi  I-icamfde  is  shown  in  Figure  1 3 as  a partial  <program>  tree. 

This  may  be  ccmj)ared  wi  IJi  thti  fjartial  tree  shcAm  in  Figure  12. 

The  second  stage  is  the  construction  of  the  abstract  program  from  the 
concrete  program.  The  <program>  for  the  running  exanple  is  shown  in  Figure  14. 
This  will  form  the  <program>  component  of  the  •<machine-state>  during  the 
interpretation  phase  of  the  definition.  In  Figure  14,  unique-naonnes  are 
represented  as  wo  have  done  before  by  means  of  circled  nurbers.  Designators 
aure  shown  by  airrows  pointing  to  copies  of  unique-names. 


Completed  concrete  program  for  the  Running  Example. 


Figure  14.  Abstract  program  corresponding  to  the  Running  Example. 
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12.  THE  WCHINB-STME  SYNTAX 

nils  part  of  the  •^nachine- stated  syntax  rules  describes  the  ■<interpretation- 
state>.  The  productions  for  -^nachine-state^  and  -^translation-state^,  rules  Ml 
through  M4,  were  given  in  section  7.1 

M5.  -^interpretation-state^  ::=  [-^progran-state^]  -^datasets-^ 

Syntax  for  program-state 

M6.  •<program-state>  ::=  -^program-control  ■>  -<s  to  rage- stated 

M7.  -<prog  ram- controls  ::=  -<oxecuta)>lc-unit-dosignator>  -^operation-list^ 

M8.  -<storage-state>  ::=  -^storage-directory-^  -<allocated-storage> 

M9.  -^storage-directory^  ::=  -^storago-directory-entry-l  ist> 

MIO.  -<stQrage-directory-entry>  ::=  <identifier>  -<basic-value-fi2signator> 

Syntax  for  allocated  storage 
Mil.  -<allocated-storage»  ::=  -^basic-value-list-^ 

M12.  -<basic-value>  ::=  -<integer-value>  I -<hit-value^  | -<unrtefined> 

M13.  -<integex-value>  ::  = 

The  terminal  component  of  an  -^Integer-value^  is  a single  element 
from  the  set  of  integers. 

M14.  -<bit-valuo>  ::=  <trix?»  I -<fal se» 

Syntax  for  datasets 

M15.  ■<data5»ts->  :;=  -^infXJt-dataset-^  -<outr)ut-dataseb> 

M16.  -<input-datasGt>  ::=  -«datasct>  -<current-position> 

M17.  -^output-dataset^  ::=  -<dataset> 

M18.  •<dataset>  ::=  -<al  pha»  [-<dataset-valuc-list>]  4onBga» 

M19.  -<currcnt-position>  ::=  -^designators 

M20.  -<data.sot-valuc?>  :;=  -<intogor-valuo>  I -<hit-value> 
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13.  THE  nriERPRETER 


In  this  section,  we  describe  the  portion  of  the  definition  algorithm 
that  defines  the  meaning  of  the  i:program}>  by  interpreting  the  correspondiixj 
<program>  constructed  by  the  translator. 


13.1  Initial i 2a  tion 

First  tlie  data  to  be  input  is  obtained  and  the  •<program-state»  is 
initial ized. 


Ojoration:  interpretation-phase 


Step  1.  Let  ds  be  a 

•<datasc  : 

■<a1pha» 

■<cmega». 

Step  2.  Obtain,  from  a source'  outside  this  definition,  information  to  be 

used  for  input,  constructed  in  the  form  of  a -^bcisic-value-l  ist»,  tvl . 
Sten  3.  If  hvl  exists  th(?n  attach  iwl  to  ds.  let  dg  be  the  <desiqnatDr>  that 

designates  tlie  -<alt-het»  of  ds.  let  dsi  be 

WinJet- da  ta  set> : 
ds 

•<currRnt-position> : 
dg. 

Step  -1.  I’erforrr.  interpret  (lisi)  . 


Ojxiration:  interjretlflsi) 

wtiero:  dsi  is  an  -^inDut-iUibaset-^ 


Step  1.  Let  (iso  be- 

■<ou4)u  t-<  la  bas(;t-> : 

-<(Litasct>: 

Sbef>  2.  Attach  to  tlK“  ^inacl i in« ?-s t a te»  tlic  tree 

■4  interprebition-state> : 
-<datasnts>: 
dsi 
dsO. 

Step  3.  Perform  activatt'-t>rT3qram. 
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Operation: 


Step  3. 


Step  1.  Let  eud  be  an  <executable-unit-designator>  that  designates  the 
first  element  of  the  <executabl e-unit-1  ist>  of  the  <program>. 

Step  2.  Attach  to  the  -^interpretation-state^  the  tree 
•<program-state» : 

■<program-oontrol  : 
eud; 

■<storage-state> : 

•<storage-directory-> 

■<al  located-storage>. 

Step  3.  For  each  <dec1aration>,  d,  perfonn  Steps  3.1  and  3.2. 

Step  3.1.  Perfonn  allocate  to  obtain  a -^basic-value-designator-^,  tvd. 
Step  3.2.  let  id  be  the  <identifier>  of  d.  Append 

•<s  bDrage-directory-entry> : 
id 
bvd. 

to  the  -^stDrage-directDry^ 

Step  4.  Append  an  -toleration^  foi'  advance-execution  to  the  -^program-control-^. 

Note  tliat  tic  execution  of  Step  4 of  tliis  operation  brings  into  existence  the 
toperation-1  isb>  of  -<proqram-oontr<Jl>.  For  as  long  as  this  list  exists,  the 
rightmost  toperation>  is  tlie  active  one  and  the  execution  of  the  rightmost 
toperation>  of  the  toperation-1  ist>  of  toontrol -stated  is  suspended.  It  will 
remain  suspended  until  tlie  -<program-oontrol > is  deleted  by  the  execution  of 
either  the  execute-retum-statonent  or  abnormal -termination  operation. 


13.2  Statement  Interpretation  Control 

These  operations  control  the  sequence  of  statement  interpretation. 


Operation;  advarce-execution 


Step  1. 
Step  2. 


Step  3. 
Step  4. 


Let  eu  the  tlic  <cxocutab1e-unit>  designated  by  the  <executab1e- 
unit-d(.'Siqnator>  of  tlie  -<pn)qram-state>. 

If  eu  iitftcd lately  contains  a <single-statenEnt>,  ss,  then  let 
st  Ix"  the  imnediatc  ccrrfcnent  of  ss.  Otherwise,  let  st  be  the 
ininf!(Jiately  contaiinxl  <i  f-statcmLyit>  of  eu. 

Perform  execute- xxx (st)  wlxue  "xxx"  is  replaced  by  the  sequence  of 
symbols  fonniiv;  the  type  of  st. 

Oo  to  r ^tep  1 . 


Operation:  normal -sequence? 


Step  1. 


Ste[)  2. 


Let  cul  be  tic  <cxocutable-imiit-1ist>.  Let  eu  be  the  <executab1e- 
unit>  of  eul  tliat  is  desicTnateil  by  the  <executabl e-uni t:-designatDr>, 
eud,  of  tlx!  -<y)rofjr.Tm-stite>. 

let  eud  dcsiiynate  tlie  <exccutal)l e-unit>  that  inmediately  follows 
eu  in  eul  . 


13.3  Interpretation  of  Statanents 


There  is  an  ofxyration  for  each  statmt-'nt  tyfie. 


Operation:  execute-if~statjan£;nt(st) 


vtiere:  st  is  an  <if-Etate5TiRnt> 


Step  1.  Let  le  be  tlie  <loqical-expression>  inmediate  component  of  st. 
Porfom  evaluate-! ogical-exfircssion(le)  to  obtain  tv. 

Step  2. 

Case  2.1.  tv  is  ■<true». 

Let  ss  be  the  <single-stataiient>  oomponent  of  the  <then-unit> 
of  st. 

Case  2.2.  tv  is  <false^. 

If  st  does  not  contain  an  <else-unit>  then  perform  notmal- 
sectuence  and  terrninatc  tiiis  operation.  Otherwise,  let  ss 
be  tdie  <sin(jlG-stateiit;nt>  component  of  the  <else-unit>  of  st. 
Step  3.  Perform  €ixccute-xxx(ss)  where  "xxx"  is  replaced  by  the  sequence  of 
symbols  foniunq  tlie  tyie  of  ss. 


Ofjeration:  execute-assignment-statanent  (st) 

where:  st  is  an  <assicinment-statfirent> 

Step  1.  Let  xp  be  the  <ex7)rcssion>  of  st.  Perform  evaluate-expression(xp) 
to  ctotain  a <basic-value>,  bv. 

Step  2.  Let  vr  be  the  ijmediately  contained  <variable-referenoe>  of  st. 

Perform  assign  {'^r,  tA’) , 

Step  3.  Perform  norTvt1-soiut.’'icc. 


Operation:  execute-<.>oto-statjcment(st) 

where:  st  is  a <(ptcr-3tatenient> 

Step  1.  Replace  the  <exccaitabl(r-uni t“desiqnator>  of  the  ■<program-state> 
by  a cxjyy  of  the  <exccutai)U>-unit-cleslgnator>  of  st. 


L 
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Operation:  execute-read-sta  tenant  (st) 

where:  st  is  a <read-staement>. 

Step  1.  For  each  <variab1e-reference>,  vr,  of  the  <variab1 e-reference-1  is t> 
of  St,  taken  in  left-to-right  order  perform  Steps  1.1  through  1.3. 

Step  1.1.  The  •<dataset-value-1ist>,  dvl , of  the  ■<input-dataset>  must  not 
be  enpty.  If  the  -^current-position^,  cp,  of  the  -<input-dataset> 
designates  •<a1^Ta»  then  let  dv  be  the  first  element  of  dvl, 
otherwise  let  ^ be  the  element  of  dvl  that  inmediately 
follows  the  one  designated  by  cp.  This  element  must  exist. 

Let  cp  designate  dv. 

Step  1.2.  Let  d be  tJie  <dec1aration>  designated  by  the  <declaration- 
designator>  of  vr.  If  dv  oontains  an  -^integer-value^  then 
d must  contain  <fixed>,  otherwise  d must  contain  <bit>. 

Step  1.3.  Perform  assign{vr,  bv) . , 

Step  2.  Perform  normal -seciuence. 


Operation:  exECute-retum-stataTTcnt(st) 

vrfiere:  st  is  a <retum-statement> . 

Step  1.  Delete  the  -<program-oontrol->  frcm  tlie  -^nachine-state*.  i 

Note  that  this  causes  the  rightmost  4operation>  of  the  -<operation-1ist>  in 
the  -<cc»itrol -stated  to  boccme  tl>e  active  operation. 


Operation:  executr-^rfritc-statBiiL-nt(st) 

where:  st  is  a <writi— 3tatnnL*nt>. 


Step  1.  For  oacli  <v.iriatjl«— n;f r-n'iirt- >,  v»  , of  the  <variablo-rBferenoe-1  ist> 
of  st,  taken  in  L-f  l-ti>-i  n^it  onk-r  , [sirform  Steps  1.1  through  1.4. 

Stejj  1.1.  Perform  evalii.Ui.*-vai  ..»i)le-refcrcncc(vr)  to  obtain  a 
-<bdsic-vulu_--tk?sign.itor>,  bvil. 

Step  1.2.  Perform  obtain-basic-value (bvd)  to  obtain  a <basic?-va1ue>, 
bv.  Let  V be  the  xjmtiiUatt'  cerponent  of  bv.  Let  dsv  be 
a -<dataset-va1iK+:  v. 

Step  1.3.  If  tlui  ncrtxir  of  elements  in  the  -^dataset-value-l ist>,  dvl, 
of  the  -<outfiut-datar.et>  is  greater  thain  sate  inpl  ementation- 
defined  niirixir,  then  forform  abnormal -termination. 

Step  1 . 4 Append  dsv  to  dvl . 

Step  2.  Perform  normal  soiuence. 
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Operation:  eval uate- logical -expression (e) 

where:  e is  a <logica1 -exjiress ion > 


result:  -^true^  or  <fa1se> 


Case  1.  e iirmediately  contains  a <variable-refenince>,  vr. 

Perform  evaluate-variable-refoxenoe(vr)  to  obtain  a -^basic-value- 

designatoir^,  bvd.  Perform  cA^tain-basioval  ue  (bvd)  to  obtain  a •<baslc-value»,  bv. 

Return  the  urinodiato  oon^wnent  of  bv. 

Case  2.  e iitmediatelY  contains  two  <ejqjrcssion>  components,  el  aind  e2. 

Step  2.1.  Perform  evaluate-cx{3ression(el)  to  obtain  a ^basio-val ue*,  bvl, 
and  evaluatr^cyi->rcnsion(o2)  to  obtain  a •<lasic-valuo>,  bv2. 

Step  2.2. 

Ccise  2.2.1.  c immcdiatol V contains  <en>. 

If  bvl  = hv2  th(xi  return  •< true^othenvisc  return  ■<false». 

Case  2.2.2.  e iirmediately  contains  <nea>. 

If  bvl  - i-)v2  then  return  -^fa  1 othen-n.se  return  ■<true». 


Operation:  evaluate-expression (c) 

whore:  c is  a <f ixed-expression> 


result:  b ue^ 


Case  1.  e inmndiatt'ly  contaj’’:;  a <vir , .>J'lr--'refexonce>,  vr. 

Perform  evaluab— varialiK  — reforr*iii  i'(vr)  to  obtain  a •<tosic-valuo-dcsiqnator^, 

bvri.  Perform  olita  in-tK'':if-valne(l)V(l)  to  obtain  i ■‘basic-value*',  bv.  Return  bv. 

Case  2.  e inmeftintr'lv  oontain;'.  a ■I'liv.t.itit , r. 

l/?t  t'V  tie  a -<1 s i v ',•/'»>)<•  '■  ir;  Hie  iirrif'diate  component  of  c. 

Return  trv. 

Casio  3.  e iirmediatelv  contains  an  <inf i:'-exr>rcssiai>,  ix. 

Step  3.1.  let  el  and  cJ.  Ixi  the  innediatcly  contained  <ejcnression> 
oemrTonento  of  ix.  T'nrform  evaliwte-expression(el)  to  obtain 
the  •^Ivi.'sic-valMe*,  Irvl  and  evaluate-exDression{c2)  to  obtain 
the  •<lasic-v.il nr-*,  J,v;i. 

Step  3.2.  If  ix  iiimefliately  contains  <c>dd>  then  let  ix  be  the  •<integer- 
value>  whose  vain*  is  the  sim  of  the  two  ^integer^value* 
comfxincats  of  tv  I aivi  bv2.  Otherwise  let  ir  be  the  ^integer- 
value^  wtioixr  value  is  Uie  product  of  the  two  ■<intfiger-valuB> 
cnmfir,nc*nf.':  of  bvl  ar>J  tv.’. 

Step  3.3.  If  tJie  rvvini tilde  of  ir  oxrfv>,ip  an  implanentation-definecl 

mayaimin.  Mu  n let  ir  tm  an  ■<in''/*qer-valiie>  with  an  iinnl fmentation 
defirKxJ  'laln*  arnl  o|'(  ioially  f<‘rrorm  abnormal -terminaticxi. 

Step  3.4  Return  -♦Kisic-vahK-^:  ir. 
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4.  e unnediately  contains  a <prefi»-exrression>,  px. 

Sten  4.1.  Let  el  be  the  <expression>  urmediately  contained  by  rw. 

Perform  eval uate-expression (el)  to  obtain  a ^basic-value^,  bv. 

Step  4.2.  Let  ir  be  the  -^integer-value^  v4iose  value  is  -iv,  where  iv  is 
the  -^integer-value^  immediately  contained  by  bv. 

Step  4.3.  If  tlie  magnitude  of  ir  exceeds  an  implementation  defined  naximun 
then  let  ir  be  an  implementation-defined  value  and  cotionally 
perform  abnorral -termination. 

Step  4.4  Return  -<basic-value»:  ir. 


13.5  Storage  Manipulation 

These  two  operations  are  the  only  operations  that  directly  change  the 
state  of  -^al  located-storage^. 


Operation:  al locate 

result:  a -<basic-val ue-designabor»  ' 

Step  1.  Let  bv  be  a -ODasic-value^:  -<un^fined». 

Step  2.  Append  bv  bo  the  -<basic-value-list>  of  -^allocated-storage*. 

Step  3.  Let  bvd  be  a -<basic-val ue-designabor>  that  designates  bv.  Return  bvd. 


Operation:  assign (vr,  bv) 

where;  vr  is  a <variabl e-ref erenoe> 
bv  is  a -Phasic-valued 

Step  1.  Perform  evaluate-variable- reference  (vr)  bo  <fotain  a -Pbasic-value- 
designatord,  bvd. 

Step  2.  Iteplaoe  the  -Pbasic-valued  designated  by  bvd  with  a copy  of  bv. 


13.6.  Storage  Reference 

Operation:  oval uate-Vcuriabl e-referenoe (vr ) 

where:  vr  is  a <variable-rcference> 
result;  a Pbasic-value-designabord. 

Step  1.  Let  d bo  the  <<lcclaration>  dcsinnated  by  tlie  inmediately  contained 
<dcclaration-ciesignator>  of  vr. 

Sten  2.  liCt  id  be  the  <idcntifier>  of  d.  Let  bvd  lx;  a copy  of  the  -Pbasic- 
valuo-designatord  oorTxxient  of  tie  Psborage-direebory-entryd  that 
contains  an  <idontificr>  ertual  to  id. 

Stop  3.  Return  bvd. 
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Operation:  obtain^oasi^val  ue  (bvd) 

where:  bvd  is  a ■<basic-va1ue-designator» 
result:  a ■<basiC“val ue» 

Step  1.  The  ■<basic-value»  designated  by  bvd  must  not  contain  ■<undefined». 

Step  2.  Iteturn  a copy  of  the  ^basic-value^  designated  by  bvd. 

13.7.  Abnomel  Termination 

Operation:  abnormal  -termination 

Step  1.  Perform  an  iiTplanentation-defined  action. 

Step  2.  Delete  the  -^program-control^  frcn  the  -^machine-state^. 

The  implanentation-de fined  action  permits  the  implementation  to  give  sene 

indication  to  the  progranmer  of  tht  reason  vAiy  the  program  is  being  abnormal  ly 

terminated.  This  operation  also  causes,  Ly  tl>e  deletion  of  the  •<prDgram- 

control*,  the  rightmost  -foperation^  of  tlic  -toperation-list>  in  the  -tcontrol- 

state>  to  beoame  the  ctetivo  operation  again. 

13.  8 Application  to  the  Running  Rxamplo 

Tb  continue  with  our  running  example,  we  will  suppose  that  the  input 
file  oontains  two  values,  the  -<bit-value>;  -<tr\ie»  and  the  •<integei~-value>:  9. 
Figure  15  shows  the  -^nechino-state^  just  before  the  operation  activate-pzograni 
is  performed.  The  -<current-positian»  of  the  -<input-dataset>  designates  the 
-<alpha»  meirker  at  the  steurt  of  the  file  and  the  -<outpub-dataset>  is  empty. 

After  the  operation  activate-progran  has  been  conpleted,  the  4 interpretation- 
stated  is  as  shown  in  Figure  I h*  tiio  ^al located- storaged  aontadns  three 
-<basic-valued  oar^jcnejits,  eacli  uiitial izfxl  to  -eundefinedd,  for  the  three 
variables,  X,  Y,  anti  The  -<storagi?-diroctaryd  contains  entries  designating 
these  values.  The  ■<executabl e-uni t-designatord  has  been  set  to  designate 


'<ijiterptetadicn-statc^ 


Statement  In  the  Running  Example. 
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the  first  statement  in  the  <progr2n»>  (shown  in  Figure  14) . The  -^program- 
oontrol*  certains  an  -^operation*  for  advance-execution  amd  this  is  rxjw  the 
active  operation. 

Following  the  execution  of  the  first  statement  of  the  <program>,  the 
READ  statement,  the  •<interpretation-state>  is  as  shown  in  Figure  17.  The 
•<a1  located-storage^  has  changed  so  that  the  ■<basic-va1ije>  oonponents  for  the 
veuriables  Y and  Z now  contain  the  values  read  from  the  •<input-dataset».  The 
<ba8ic-va1ue>  for  X is  unchanged,  it  is  still  ^unciefined>.  The  ^current- 
position>  of  the  <<input-data3et>  now  designates  the  value  just  read  from  it 
and  the  4executable“unib-designator»  has  been  advanced  to  the  next  statement. 

Figure  18  shows  thie  •<interpretation-state>  f ol  lowing  the  execution  of  the 
IF  statement.  The  ^basic-val ue>  for  the  variable  X has  now  received  the 
•<intoger-valiie>  19  because  the  <then-unit>  was  executed  since  the  ^basic-value^ 
for  Y contained  ■<true>.  The  <executabl  e-uni  t-designator>  has  been  exlvanoed 
to  designate  the  WRITE  statement. 

Ebcecution  of  the  WRITE  statement  causes  a copy  of  the  •<inbeger-value» 
for  the  veuriable  X to  be  appended  to  the  ■<output*dataset> . Since  the 
■<output-dataset>  was  aipty,  a •<data8et-value-list>  was  constructed  by  the 
append  instrvetion.  The  ■4output-dataset>  is  as  shown  in  Figure  19.  At  this 
point,  th»e  -^executabl  e-uni t-designator^  designates  the  RETURN  statement 
constructed  by  the  Tremslator.  Execution  of  this  statement  causes  the 
program  to  terminate. 
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statemervt  in  the  Running  Example. 


Mlnteipcetatlon-atate* 


Statement  In  the  Running  Example. 


tior^state^ 


Fiqure  19.  The  •^intserpretation-statfi^  just  prior  to  Interpreting  the  RETURN 

^ . . A * _ M 1 ^ 
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I 

• 14.  Poatlude 

j - This  definition  of  the  trivial  language  SAL  has  used  the  definition 

I . technique  of  BASIS/1;  however,  we  have  only  introduced  those  terms  and 

concepts  that  were  required  for  specifying  this  small  language.  The 
reader  who  is  using  this  as  an  introduction  to  BASIS/1  will  find  that, 
because  of  the  much  greater  complexity  of  PL/I,  some  additional  constructs 
have  been  needed  for  its  definition.  Nevertheless,  the  mechanism  used  here 

i 

is  essentially  the  same  as  that  used  BASIS/1  and  a reading  of  the  first 
■ chapter  of  BASIS/1  will  serve  to  Introduce  the  additional  features  of 

the  metalanguage. 

I 

The  BASIS/1  metalanguage  is  sufficiently  powerful  to  give  formal 
definitions  for  any  sequential  programming  language,  such  as  ALGOL  60, 
SNOBOL,  LISP,  or  COBOL.  However,  since  tasking  is  not  considered  in 
j the  BASIS/1  version  of  PL/I,  the  method  in  its  current  state  is  not  suitable 

I for  defining  non-deterministlc  or  parallel  programming  languages  such  as 

ALGOL  68. 

We  would  like  to  thank  Uavld  Beech,  Jolin  Kelly,  Henry  Ledgard,  and 
Peter  Wegner  for  their  helpful  comments  on  previous  drafts  of  this  paper. 
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